コメント†
- official:自作プラグイン/codehighlight.inc.phpに使ってみました。 (10/29 変更)-- sky
if (preg_match('/^(#.*)<<([A-Z0-9_]+)$/',$line, $matches)) {
+ if (preg_match('/^(#.*)\((.*)\)$/',$matches[1], $mat)) {
+ $line = $mat[1]. "(" . $mat[2] . ",";
+ } else {
+ $line = $matches[1] . "(";
+ }
$line = $matches[1] . "(";
このようにすれば #name(arg)<<EOF の形で呼び出せます。プラグインの引数でargとヒアドキュメントを区別したい時に使っています -- sky
- ユーザ定義ルール(&now;など)は展開されてしまうようです。 -- matsuda
- ユーザ定義ルールの置換を抑制できるようにしてみました。 -- matsuda
#name<<PRE:EOF
...
EOF
convert_html.php.2.diff
file.php.diff
- 関連ありそうなページを発見（書式再定義/ブロック構造の実現）。 -- matsuda
- PRE: の時にカンマ , を展開しない方法を考えた方は教えて頂けませんか。現在は応急的対策として一度別の文字に変換してからPluginで元のカンマに戻しています。これだと全てのプラグインに逆変換させなければいけません。 -- sky
- convert_html に次のコードを追加して、プラグインで"& sbquo;"をカンマに置換しています。
$stop_word = $matches[3];
while (count($lines)) {
+ if (substr($matches[2], 0, strlen('PRE:')) == 'PRE:'){
+ $lines = preg_replace("/\,/", "‚", $lines);
+ }
$next_line = array_shift($lines);
if (substr($next_line, 0, strlen($stop_word)) == $stop_word){
- 通常の引数の記述ができるようになったので、ヒアドキュメントの部分はカンマによる分割をしないほうが良いですかね。「‚」というのは、入力される文字列には絶対現れないでしょうか。 -- matsuda
- PRE:のありなしに関わらずカンマによる分割をしないようにすれば、インライン型プラグインの&name(){...};の記述と対応するので美しい気がします。 -- matsuda
- カンマによる分割をしないようにしました（v1.2)。最初の"\r"を通常の引数とヒアドキュメントの区切りにすることで、特殊な文字の使用を避けてみました。 -- matsuda
- 素早い対応ありがとうございます。引数が無い時にはこれまで同様カンマで分割されてしまうため、引数の代わりにカンマを挿入するようにしました。 -- sky
- これ(v1.3)だと、空の引数が２つ出来てしまいますね。 -- matsuda
- plugin.php側の修正にバグがあったので直しました(v1.4)。 -- matsuda
- ヒアドキュメントは主に出力として使用されると思われるので、あらかじめサニタイズしたほうが良いでしょうか。サニタイズした場合、用途が制限されてしまうような可能性はあるでしょうか。 -- matsuda
- 今のヒアドキュメントのプラグインへの渡し方ではヒアドキュメントが通常の引数と区別できないため、必ずプラグイン側で再度サニタイズが必要になる。 -- matsuda
- 私も時々、どういうカタチ(UI含む)にするのが使いやすいだろうか、あるいは実現できるのだろうかを考えている今日このごろです。 -- henoheno
- けっきょく、ヒアドキュメント構文が理解できるのはプログラマに近いひとだけだとおもいます。*1まだ、amazonプラグインのように #amazon(...) ～ #amazon(clear) （でしたっけ？）のほうが分かりやすいかとおもいます。 -- みこ
- ちなみに、上記のような形式（ヒアに近い形）であればインラインでは以下のようにおこなってほしいんですけどね。 -- みこ
&sample(arg1,arg2,arg3){ ←{のあとはすぐ改行(判定を甘くするならTrimもあり)
複数行のもの
複数行のもの
複数行のもの
};abcdef ←改行の直後に};で判別。そのあとのabcdef はそのまま続行
- そのままブロック型に応用するならこんな感じかな・・・ -- みこ
#sample(arg1,arg2,arg3){ ←{のあとはすぐ改行(判定を甘くするならTrimもあり)
複数行のもの
複数行のもの
複数行のもの
} ←改行の直後に} + [改行]で判別。ブロック型なのでこれ以外何もない。
abcdef
- 終端を固定の文字列で表そうとすると、じゃあその文字列を含めたいときはどうするんだ、って問題が必ず発生するんですよね。 -- matsuda
- なお、HTMLの構文解析と同様でヒアの終端を記述しない場合は「そのまま」見せるほうが（失敗したということも含めて）わかりやすいかとおもいます。 -- みこ
- これはその通りですね。その場合、複数行にわたった文字列をそのまま出力すると、ブラウザ側で連結されてしまいますが、そこはどう扱うのが良いのでしょう。-- matsuda
- いままでのPukiWikiと同じように「ありのまま」でいいんじゃないでしょうか？（プラグインが存在しない場合は処理せずそのまま出力していますよね？） -- みこ
- {{ }}で囲むスタイルなら、連結されても見た目に分かりやすいですね。 -- matsuda
- みこさんの案が素晴らしいと思います。Wikiの文法に潜む共通のルールのひとつ「繰り返し」が生きています。実際の実装を考えると、繰り返し数は 2～n がよろしいかと思います。(1つの場合は従来通り、1行しか見ない様にしたほうが処理的に優しく、覚えてもらう基本ルールとしては2つとするのが人に優しそうです)実装については、ヒアドキュメントを作られた皆さんが一番近いところにいらっしゃるでしょうか? 今心配しているのは、その間で #include プラグインなどでインクルードしたなかにそのデリミタ(nコの閉じカッコ)が存在していたらどうなるかですね。やってみた方が早いですが :) -- henoheno
- convert_html.php5.diffでどうでしょうか。繰り返し数は 1以上です。 -- sky
- 次のようにしないと、"()"が省略できませんでした。*2 -- teanan
- if (preg_match('/^(#[^\(]*)(\((.*)\))?(PRE:)?({+)$/',$line, $matches))
+ if (preg_match('/^(#[^\(]\w+)(\((.*)\))?(PRE:)?({+)$/',$line, $matches))
- 修正ありがとうございます。 -- sky
- 残るはいかにもプログラムっぽい PRE: をプラグインの引数に入れることですね (^^) -- みこ
- このあたりは、上の正規表現を見る限り擬似引数として解釈させることは可能でしょうか？ -- みこ
- 例えば "{{PRE:" として引数のように見せかけると言う事でしょうか。"()"を省略するとプラグイン名と"PRE:"が続いてしまうのでこっちの方が良いと思います。この方式でのプラグイン呼び出しは出来ています。 -- sky
- いえ、最後の引数とする（例： #sample(arg1,arg2,pre) の pre）とするという意味です。これができなければ結局ヒアドキュメントと何らかわりはないですしね。 -- みこ
- んじゃ引数じゃない方向も。通常記述が#sampleの時、preの記述は整形済テキスト＝空白なので、空白あけて# sampleとか。あるいは太字＆斜体ルールの様に#を重ねた数に意味を持たせて##sampleとか。…うーん余計混乱するかなぁ。 -- にぶんのに
- 複数行処理用の引数案。通常の引数とは区別が必要だと思うので #sample(arg)[pre]{{ }} -- matsuda
- えっと、区別する理由って技術的要因以外になにかあるのでしょうか？ (^^; -- みこ
- preっていうのはすごく汎用的な単語なので、予約語にしてしまうのは抵抗感があります。衝突しないように特殊な記号をつければ使い勝手が悪くなりますし。 -- matsuda
- では、ちゃんとした単語を用意すればいいのは？（実際にプラグインの意味からすると、整形ではないし）たとえば、preformatted とか noparse とか*3・・・ -- みこ
- 例としてあげられた単語は、いかにも通常の引数として渡したいような単語に見えます。 -- matsuda
- いっそのこと、複数行引数形式のときはユーザ定義ルールは適用されないとか。 -- matsuda
- そのほうがいいかもしれませんね (^^; 必要ある人がどこまでいるかにもよりますが・・・ -- みこ
- 逆転の発想で、プラグイン引数でユーザ定義を適用したいなら、プラグインで何か引数を用意してもらってプラグインの中で make_str_rules を呼んでもらう・・・というのはどうでしょう？＞matsudaさん -- みこ
- &now;はプラグインの実行時の解釈では意味が違って
しまいますねしまわないでしょうか。 -- matsuda
- なるほど。コンバート時に置換はともかく、ソースを直接置換に関してはそうかもしれませんね。 -- みこ
- いろいろ考えてみたんですが、本来の Wiki のパターンに沿わせるならば、やはり複数行の中でも空白が先頭にあった場合のみ整形済みテキスト*4扱いするのが正論だとはおもいますけどね・・・（ソースを埋め込みたい人にとっては面倒なのでしょうけど (^^;） -- みこ
- 逆に、プログラムソース以外で変換されたくない需要ってあるのかな？ (^^; -- みこ
- 自分もユーザ定義ルールを適用したくないケースはプログラムソースがほとんどだと思います。なのでユーザ定義ルールの適用を除外する記述がいかにもプログラム的であっても「使い勝手」上は問題ない気がします。ソースの場合は特に行数が多くなり勝ちなので、先頭に空白を入れるのは何とかして欲しいと思います。 -- matsuda
- プラグインが適用されない場合にソースのまま出力されるようにしました。 -- matsuda
書式
#sample(args)[nosubst]{{
...
}}
convert_html.php.7.diff file.php.2.diff
convert_html.php.6.diffはバグっているので使わないでください。-- matsuda
- ソース置換を区別するためにだけならば、（どのみち複数行なんだから）いっそのこと中括弧に拘らないほうが楽かもね・・・ 大括弧とか (^^; -- みこ
#code_highlight(c)[[ ←(1～n)
void main(int argc, char *argv[])
{
printf("hello world.\n");
}
]] ←(行頭で1～n)
#plugin((
arg
))
- '上のように普通の括弧を従来のプラグイン引数と同じどうさをした複数行拡張にしたら紛らわしいでしょうか? -- sky
- 上記（通常の括弧）でも、複数の引数が欲しい場合に同様の感じ（最後に複数行の引数）になるならば OK なのでは？ -- みこ
- ただ、文法は安易に拡張をするとあとで収拾が付かなくなる*5ので、（標準に採用されるならば）できる限りディスカッションしたほうがいいと考えています。 -- みこ
- 極端に言うとユーザ定義ルールは UI のお話（文法のお話ではなく置換マクロを文法っぽくみせている）なので外部プラグインで制御も可能かなとおもう部分もあります。以下例↓ -- みこ
#nouserrules ←このプラグインでページ内のユーザルール全体の書き換えを抑制
#sample(arg1,arg2,arg3){{ ←{(1～n)のあとはすぐ改行(判定を甘くするならTrimもあり)
複数行のもの
複数行のもの
複数行のもの
}} ←改行の直後に}(1～n) + [改行]で判別。ブロック型なのでこれ以外何もない。
- いえ、そこまでもいらないと思います。元々、行メタなPukiWiki は on/off だけあればいいので制御する場合はブロックにする必要はないです。すなわち
#nouserrules(on)
:
でほおっておいてもいいし
#nouserrules(on)
:
#nouserrules(off)
としてもいいという意味です。でもって、引数なしのデフォルトは on もしくはトグルが理想かな・・・ -- みこ
- ↑ちなみに上記は、skyさん/upkさんの部分編集のon/offよりヒントを得ていますplus:開発談義/4 -- みこ
- ただ、あくまでも一案（しかも極論）です (^^; ＜別プラグイン -- みこ
- 別プラグインというのは綺麗な表現だなと感じました。疑問点はその効果を複数行引数とするのが良いか、それとも全体におよぶのか。また部分的にコピペしたときにユーザ定義ルールが適用されてしまう可能性があるので気をつける必要があります。複数行引数以外は行指向なのでそういう煩わしさが無いぶん余計に気になるかも。ソースコードを書く場合を考えると[[ ]]でユーザ定義ルールOFFというのが使い勝手がよさそうですが、ブラケットネームとかぶるのはどうなんでしょう。 -- matsuda
- わたしも、*8その部分は気になっていました (^^;＞中括弧以外の括弧を使用 -- みこ
- 別プラグインによる場合のお話ですが、これはどっちにも言えるので（もともとsetlinebreakなどに近い）似たような実装でいいのではないかとおもいます。すなわち、全体でおこなってもいいですし、複数行引数のみにしてもいいのではないかと（どちらかであって、それを引数で指定はめんどいのでなしね (^^;） -- みこ
- ちなみに現在でも、（[nosubst]なしで）行頭に空白を入れていると、いまでもユーザ定義ルールは置換されないのですね (^^) -- みこ
当面、ユーザ定義ルールは抑制できなくても良い気がしてきました。-- matsuda
- やっと「複数行引数でも先頭の空白で表すのが正論」がのみこめました。 -- matsuda
- 複数行引数は整形済テキストというわけではないから、先頭に空白があってもユーザ定義ルールを適用するのがスジですかね。-- matsuda
- 複数行の引数を最後の引数に限定しているのが不満。何番目の引数でも複数行に書ける記述が出来るといいと思う。 -- 外野
- ２つ以上の複数行の引数を使う想定が思いつかないのでおしえてください。どのような場合（プラグイン）を想定されていますか？＞外野 -- みこ
- 同時に複数行の引数を使うケースはまず無いでしょう。既存のプラグインを使いまわす場合、1つめの引数で使いたい場合もあります。 -- 外野
- そのプラグインってどれになるんでしょう？ (^^; オフィシャルプラグインでは１つ目の引数で複数行がほしいというのは見当がつかなかったのですが・・・＞外野 -- みこ
- official:自作プラグイン/div.inc.phpが当てはまるかも知れません。 -- matsuda
- 外野さんは同時にはないといっているので、違うかと (^^; 唯一オフィシャルで思いつくのは #back プラグインぐらい？ -- みこ
- 違った見方をすれば ref のように引数が多くなるプラグインでしょうか。長いURLと複数のオプションの場合は複数行に書きたくなります。(私も#divの代わりに自作品を使っています) -- sky
- たぶん、実現するなら過去にreimyさんが発言された以下の形式が近いでしょうけど、そんなに需要があるのかな？これって・・・（下記は{{ が複数行としてちょっとアレンジしています。） -- みこ
#hogehoge({{
hogera
hogetta
}},{{
hogeme
hogereba
hogetatoki
}})
- いまはサンプルとして複数行が２行ぐらいしか書いていないけど、１００行あって記述ミスしたら絶対に（どこが記述が間違っているのか）悩みそう。「お手軽に」という意味では、最後の引数のみのほうがトラブルが少なくて楽だとおもいますが・・・（テクニカル的にはどうですか？＞matsudaさん） -- みこ
- ちなみに、わたしが発言する「お手軽に」というのはいくつかごっちゃにいってますが、上記の場合WikiWikiWebが本来もっている”メール文章を貼り付ければすぐにページができる”（＝チープなデータ記法でリッチなプレゼンテーションが得られる）という意味です。（コンテンツを作るときに文法にかまっていられないというのもありますが・・・ (^^;） -- みこ
- 最後以外の引数も複数行を許そうとすると結構大きな変更になると思います。おそらくdo_plugin_convert()を、分解済の引数を配列で渡せるように変更することになるでしょうが、plugin.phpからconvert_html.phpに引数分解の仕事が移ることになるのであまり手を出したくはないです。 -- matsuda
- けっきょく、開発者・利用者ともメリットがない*9なら、現行の最後の引数のみにして、手をださないほうが無難かもしれませんね (^^; -- みこ
- プラグインに問い合わせるインターフェースを考えてみました。汎用的にするための部分も入っています。 -- みこ
- 個人的には ( ( ～ ) )はユーザ定義ルール展開し、{{ ～ }}は展開しない、のような形のほうが分かりやすくて良いような気がします。 -- teanan
- そのときの問題はかっこだと脚注、大括弧だとBracketと勘違いしそうということだけなのですが、そのあたりはどうでしょう？ -- みこ
- 前々から思いついていた折衷案として、({ ～}) （違う括弧を取り混ぜる）というのも考えたんですけど、いかにも安易で受け入れられそうにないかなぁとおもって言わないではいたのですが・・・ (^^; -- みこ
- 外部プラグインでの制御（#nouserrulesのところ）に関してですが、いっそ汎用化して他のプラグインの動作ヒントを与えるだけのプラグインというのはどうでしょう。 -- jitte
例えば
#hint(クラス,トピック,値)
と書くと、内部的にはグローバル変数に
$pukiwiki['hint'][クラス][トピック] = 値;
のように保持される。デフォルト動作はあらかじめ
$pukiwiki['_default'][クラス][トピック] = デフォルト値;
のように定義しておいて、プラグインからは
get_hint(class, topic);
のようなAPIでアクセス。ヒントがあれば使い、なければデフォルト動作が選択される。というイメージです。
- もともとは、すべてのグローバル変数を１つに集約してしまえばグローバルスコープが汚染されないし、各関数でのglobal宣言が楽になるし、ユーザごとのカスタマイズやページごとのカスタマイズも表現できるんじゃないかなぁというところからの発想です。*10 -- jitte
- 開発者からみるとそれでいいのかもしれませんが、利用者はおそらく何のヒントを与えていいかわからず、結局使わないかと思います。 -- みこ
- （ただ、上記の汎用化はヒントプラグインのために使用するのではなく、グローバル変数の集約化と xxx.ini.php の単純化といういみでは非常に賛成です (^^)） -- みこ
- 話がそれてしまいますが、その辺をうまく行っているソフトウェアでは GNU Mailman が理想的かなとおもってます。（Default.py と mm_cfg.py があって、ユーザは Default.py で項目を知って mm_cfg.py に記述して設定する。そして、GUI は他のファイルに設定し、 default.py -> mm_cfg.py -> GUI設定ファイルの順によみ設定を上書きしていく） -- みこ
- ふむふむ。使用例等のネタは多少あるのですが、もう少し考えてみて、まとまったらBugTrackにあげてみようと思います。 -- jitte
![[PukiWiki]](image/pukiwiki-dev.png "[PukiWiki]")
