複数行のプラグイン引数を可能に -- matsuda†
プラグインで何行にもわたるような文章を処理したい場合に便利な機能です。
pukiwiki-1.4.6より本体に実験的に取り込まれました。(BugTrack2/84)
パッチは必要ありません。設定ファイルに以下を加えると機能します。
define('PKWKEXP_DISABLE_MULTILINE_PLUGIN_HACK', 0);
変更履歴†
ブロック型プラグインで複数行の引数指定が可能になります。
#name(arg){{
複数行の引数
...
}}
(arg)は省略できます。
- ブロック型プラグインの通常の記述#name(arg)に続いて二文字以上の{を続けます。
- 引数は次の行から書きます。
- {と同じ数の}が行頭に現れるまでが引数として扱われます。
複数行引数の行頭に}}をおきたい場合は、引数を囲む{{ }}の文字数を調整します。
#name(arg){{{
}}
}}}
ユーザ定義ルールの抑制†
現在この機能は無効です(パッチv1.5~)。下記は古い仕様です。
また、PRE:を加えれば、ユーザ定義ルール(&now;など)のページ書き込み時の置換を抑制することができます。
#name<<PRE:EOF
...
...
EOF
プラグインのインターフェース†
この仕様は将来、おそらく修正されます。
複数行引数はplugin_xxx_convert()に最後の引数として渡されます。
(複数行引数には改行が含まれているため、通常の引数と区別できます。)
過去の話題
仕様検討†
別のページに分けられています。
複数行の引数が改変されてしまう: 見出しやユーザー定義ルール†
- 引数を含む文字列を返値としているpluginの場合、行頭にアスタリスクが書かれると見出しのアンカーが表示されてしまうようです。 -- hiroppi
- たとえばどういう記述ですか? -- matsuda
- おそらく、以下のような記述かと・・・ (^^; -- みこ
#multiline(){{
*見出し1
内容
内容
**見出し2
内容
内容
}}
- なぜ知っているかというと、実はplus!はそれを有効利用しているから (^^;(plus!のmultilangプラグイン) -- みこ
- なるほど。これはユーザ定義ルールと同じ関数内の処理ですね(ぜんぜん周りを読んでなかった)。抑制は共通のスイッチでよいのだろうか。 -- matsuda
- 言葉足らずで申し訳ないです。その後、ぼくの環境では以下のようなpatchを作成しました。共通のスイッチが使えるならばその方がいいと思います。 -- hiroppi
--- file.php 2005-01-29 22:29:34.000000000 +0900
+++ /var/www/html/pukiwiki/lib/file.php 2005-04-18 11:37:58.000000000 +0900
@@ -67,8 +67,17 @@
foreach ($str_rules as $rule => $replace)
$str = preg_replace('/' . $rule . '/', $replace, $str);
+ // multiline block plugin
+ if (preg_match('/#[^{]*(\{{2,})\s*$/', $str, $matches)) {
+ $stop_len = strlen($matches[1]);
+ $multi_block_plugin = true;
+ }
+ if (preg_match('/\}{'.$stop_len.'}/', $str))
+ $multi_block_plugin = false;
+
// Adding fixed anchor into headings
if ($fixed_heading_anchor &&
+ !$multi_block_plugin &&
preg_match('/^(\*{1,3}(.(?!\[#[A-Za-z][\w-]+\]))+)$/', $str, $matches))
{
// Generate ID:
- ユーザー定義ルールと固定アンカーについては、hiroppiさんのアイデアで問題なく動く(回避できる)ようですね :) -- henoheno
- アップロードした v1.6-for146 にマージしてあります。 -- henoheno
- V1.6-for146でmultiline block plugin の正規表現において # がエスケープされていなく、正常に動作しませんでした。 1.4.6_rc のconvert_html.php 内では、148行目と、856行目でしょうか。 とりあえず、「preg_match('/^#(」 を 「preg_match('/^\#(」に変えると動作します。 -- ryutiki
複数行の引数が改変されてしまう: 現行の「書き換え」型プラグインによるもの†
これが
#multi_sample_convert{{
hoge
#memo(この行は編集される事を意図していない)
fuga
}}
#memo(※何か実際のメモ ← ここに表示されるmemoプラグインを更新する)
こうなる
#multi_sample_convert{{
hoge
#memo(※何か実際のメモ ← ここに表示されるmemoプラグインを更新する)
fuga
}}
#memo(※何か実際のメモ ← ここに表示されるmemoプラグインを更新する)
- パッチあてずの当て推量&些細な事なのですが。 #commentなど挿入位置を調べるためページを読むプラグインがあります。複数プラグインの記述箇所は走査をスキップする対応が必要ではありませんか? -- にぶんのに
- 必要そうです :( 私は複数行のアイデアを用い、別のAPIとして用意することで例えば #memo プラグインがより便利な形に生まれ変わるのではないかと思っていたのですが、同じ問題に思い当たりました。 -- henoheno
- 現状PukiWikiプラグインによる「テキスト書き換え」は個々のプラグインが担当しており、ほとんどが行指向のシンプルな実装ですから:
- 個別に対応する場合、走査をスキップする方法を確立したとして、現行の全ての「自己書き換え型」プラグインにそれを盛り込まねば、複数行の引数とバッティングしてしまうでしょう。(方法を確立したとして)付属のプラグインの全てにそれを実装し終わるには時間が必要です -- henoheno
- PukiWiki本体で解決しようとする場合、実現できるかは別として、例えばテキストをいくつかのブロックに分割して、ブロックごとに処理する(無視する)かどうかを指定する方法があるとは思うのですが、現行のプラグイン実装はそこまで複雑ではありません(必要がないので)。 -- henoheno
- 「何番目に検出されたmemoプラグインか」といった情報を渡す仕組みがあっても回避できそうですが、現状はそんな仕組みはありません。 -- henoheno
- 他には、複数行の引数の部分の行頭に、一時的に半角スペースを挿入することで回避できるかどうか? -- henoheno
- 今までは、たまたまそのような事例が無かったのでしょうし、「自己書き換え型」複数行プラグインの需要も無かったので話がここまで行かなかったのでしょうけれども、既存の自己書き換え型プラグインと標準的な複数行プラグインが干渉するというのはとても大きな問題だと思います (^^; -- henoheno
- ざっと読んだだけなのでズレてるかもしれませんが、複数行状態である必要性はソースの可読性の問題であって、複数行プラグイン側が改行込みの引数を要求しているわけじゃないと思うのですが合ってますか? --
- もしこの認識で合ってるのであれば、ディスク保存時に単一行状態に変換・ソース表示時に複数行状態へ逆変換が行なえれば問題は解決すると思いますが。 --
- コメントありがとうございます :) テキスト保存時(単一行テキスト) / 編集時(複数行テキスト) / 表示時(複数行プラグインの引数) でそれぞれ形態を変換する案という事でしょうか。現行のルールの中でもうまく行きそうな案だと思います :) -- henoheno
- ただ、現在複数行の引数を希望しているみなさんのイメージは、あくまでもテキスト保存時の形態も複数行テキストである事を希望している様に受け取っています。(保存したテキストファイル(wiki/*.txt)と、編集時のテキストが同一) -- henoheno
- テキスト保存時に改行を \n に変換して格納するような動作自体は、例えば #memo プラグインが行っています。 -- henoheno
- 保存テキストと編集テキストの同一性を要求するならこの方法は却下ですね。フロントエンドだけの処理にすればconvert_html等を変えずに既存プラグインも改変無しに複数行引数が可能にもできそうな気がしたのでコメントしてみました。 --
開いたままのバラグラフに対し自動的に閉じパラグラフが付加される時の「開」判断について†
不思議な動きを見かけたのでどなたかご確認をお願いします。pukiwiki1.4.7を使用しています。
任意のページに
//#plugin(){{
と1行書いて保存すると、自動的に
//#plugin(){{
}}
とパラグラフの「閉じ」が付加されてしまいます。コメントアウトしてあるにも関わらずです。
改善のため、/lib/file.phpの114行に以下の変更を加えてはどうでしょうか。
前:preg_match('/#[^{]*(\{\{+)\s*$/', $line, $matches)) {
後:preg_match('/^#[^{]*(\{\{+)\s*$/', $line, $matches)) {
ただ、これはプラグインが行頭に書かれる場合に限っての処置なのですが、これは
-#plugin(){{
のようにリストやテーブル内に書き込まれる想定は必要でしょうか?その場合は上記変更では対応できないのですが。
- pkwkのバージョンアップのため、replaceプラグインで #plugin()<<_BLOCK_ を #plugin(){{ に置換したら自動的に }} が付加されてびびりましたw 先に /^_BLOCK_$/→}} を置換することで置換に成功しましたが、その過程でこの動作を発見しました。 -- フォルグロス
- なぜ自動追加の処理があるのでしょうかね?得てしてそれが正しい所に置かれたとは思えないし、いわゆる、小さな親切大きなお世話、な気がします。 --
コメント†
- 以前のコメントは./昔のコメントに移動しました。
- PukiWiki 1.4.5-1対応のパッチをアップロードしました。{{ }}スタイルです。ユーザ定義ルールの抑制は除いてあります。 -- matsuda
- これまでは引数の最後が改行である事を利用して複数行引数を見分けていたのですが、それが出来なくなったのですね。
それと、ページ長くなり書き込まれた場所が分かりにくいので分割しませんか? -- sky
- 一瞬、将来のPukiWiki-1.5で採用されたのかと思いました (^^; -- teanan
- なるべくクリーンなパッチの方が本体に採用されやすいかなぁ、なんて思ってるんですがどうでしょうか。互換性を維持したパッチの方が良いですかね。 -- matsuda
- これに関しては他のパッチと違って、使っているのは基本的には冒険者だから、互換性はあまり考えなくてもいいのでは? :) *1 -- みこ
- ただ、最後の引数のお話はたしかに指標(プラグイン作者にこう作ってくださいというルール)が必要になるかもしれませんね。(最後の引数が「改行付き」でいいのかな? (^^; ) -- みこ
- それが可能なのであれば、クリーンなパッチを希望します。利用者に届けたいのは検討の結果ですので :) -- henoheno
- code(highlight) プラグインの方で非互換情報が出ているようです。どのようなものかは未確認ですが。 -- henoheno
- マージのために気を使っていただいてありがとうございます。 -- henoheno
- 最後の引数に対応して頂きありがとうございます。code.inc.phpで動作しました。
これまでの版では結果的に最後が改行になったので、これを利用して場辺り的に区別していました。もしも引数が明確に区別出来るならこのような判定をする必要は無くなります。
仕様として引数を区別させるか否かも問題になりそうですね。区別の仕方によっては複数行引数に対応させたプラグインしか動作しないようになってしまいますし。 -- sky
- なにも考えずに・・ということであれば、最後の引数は複数行(インラインプラグインの最後の引数は自動的に{ ~ };の部分と同様の考え)ということにしてしまえばいいのですが、互換性をとりにいくのが大変そうですね。(逆にブロック型も同様にしてしまうと、既存プラグインに影響がでるかな? (^^; でも、既存プラグインもメリット得たりして (^-^(例:refプラグインのタイトル) -- みこ
- プラグインが動きません・・・。convert.html.phpとplugin.phpにパッチを当ててアップロードすればいいだけですよね?1.4.5_1の場合は? -- アッカ
- 1.4.6ならパッチをあてなくてもpukiwiki.ini.phpにdefine('PKWKEXP_DISABLE_MULTILINE_PLUGIN_HACK', 0);を加えれば動きます。1.4.5_1の場合はv1.6のパッチをあてて下さい。 -- matsuda
- アンケートを削除しました。ご協力有難うございました。 -- matsuda