[[書式再定義]] [[:CategoryDev]]

もともと(1.3まで)が行指向でブロックという考え方が無かった。

プラグインのブロック構文には下記のような書式が考えられますね。 - [[ゆう]]
上の書き方の方がスマートですが、終わりの}の後にも何か書けてしまってちょっとイヤな感じじゃないですか?
 #hogegege(zz) {
   foo bar baz
 }

 #hogehoge(zz)
   foo bar baz
 #end
-ブロックの閉めは # だけってのは乱暴ですかね?さすがに乱暴かな…。 (^^; -- [[kawara]] SIZE(10){2002-07-26 (金) 19:32:40}
-SIZE(9){ブロックをプラグインで実現するにはそのプラグインがブロック構造を持つことを本体に知らせる必要がありますね。って、そこは書式とはちょっと違う話になっちゃうな。} -- [[kawara]] SIZE(10){2002-07-26 (金) 19:35:10}
-これは書式というより、プラグインの仕様次第ですね。極端な話、プラグインのネストも許したりして(笑い) -- [[reimy]] SIZE(10){2002-07-26 (金) 21:13:34}
-{と}はCOLORやSIZEで使ってるけど競合はしないのかな? -- [[reimy]] SIZE(10){2002-07-26 (金) 23:32:23}
-上はインラインプラグイン、下はブロックプラグインって方法もありますね。 -- [[ゆう]] SIZE(10){2002-07-27 (土) 00:17:20}
-インラインであれば行頭に書く必要はないですね(というか行頭に書かなければいけないというのではインラインにならない) -- [[reimy]] SIZE(10){2002-07-27 (土) 04:23:06}
-&calc(hogehoe)ですかね?<インライン -- [[ゆう]] SIZE(10){2002-07-28 (日) 13:27:15}
-上記のような定義の仕方だと、ブロック構造の引数は1つしかとれないことになりますね。次のようにすれば複数のブロック構造を引数に取れるのでは? -- [[reimy]] SIZE(10){2002-07-29 (月) 17:09:45}
 #hogehoge({
 hogera
 hogetta
 },{
 hogeme
 hogereba
 hogetatoki
 })
-プラグインのブロック構造が実現すると、表組みの右寄せとかができるようになるね。期待してます。 -- [[reimy]] SIZE(10){2002-07-29 (月) 17:01:56}
 #align(RIGHT,{
 |東京|名古屋|大阪|
 |フジ|東海|関西|
 })
-だんだん複雑になってきちゃってますが・・・・[[HTMLの再開発]]にならないことを祈ってます。 --  SIZE(10){2002-07-30 (火) 07:04:17}
-個人的にはTeXの書式が使えればいいんだけど(^^;; -- [[reimy]] SIZE(10){2002-07-30 (火) 07:34:26}
-TeXWiki作ってみません?(笑>reimy -- [[ゆう]] SIZE(10){2002-07-30 (火) 13:11:47}
-HTML再開発になってきている気はするんですよ。私も。LEFT, RIGHT,SIZE,COLORもプラグイン行きですよね。 -- [[ゆう]] SIZE(10){2002-07-30 (火) 13:14:55}
-ブロック構造の引数は一つでいいと思います>reimy -- [[ゆう]] SIZE(10){2002-07-30 (火) 13:15:53}
-インラインの書式は&size(1){test}でいいんじゃないですかね。 -- [[ゆう]] SIZE(10){2002-07-30 (火) 13:16:40}
-難しいことをしたい場合はプラグインっていうノリだから車輪の再発明にはならなくて済むと思いますよ。基本の書式使うだけでけっこう文書作れちゃいますもんね。 -- [[kawara]] SIZE(10){2002-07-30 (火) 13:27:09}
-その場合、&size(1){&color(red){small red}}をどうやって許すかだよなー。ブロックの引数内に}があったらそこで終わってしまうし。{}内はWiki書式とは限らないから{}の対応が取れてるとは限らないし。基本的には{}対応が取れてるとしてそれ以外に}を使いたい場合はやっぱりエスケープしかないなぁー -- [[ゆう]] SIZE(10){2002-07-30 (火) 17:34:14}
-ラインパースで正規表現使ってなんとかしようと考えるとかなり辛そうですよね -- [[kawara]] SIZE(10){2002-07-30 (火) 19:58:52}
-インラインプラグインの書式を&hoge<.....>にすれば解決するでしょ。{ }にしなければユーザー定義も中で使えます。 -- [[reimy]] SIZE(10){2002-07-31 (水) 00:22:18}
--<だったら次にプラグインの中に<ほげほげ>って書く時にこまるから同じですよ。 -- [[ゆう]] SIZE(10){2002-07-31 (水) 01:08:45}
--SIZEやCOLORもインラインプラグインにしようと考えてるんですよ。そうすると難しいかなぁ・・・ -- [[ゆう]] SIZE(10){2002-07-31 (水) 01:12:51}
--プラグインの中にプラグインを持ってくるとかなり厄介か・・ -- [[ゆう]] SIZE(10){2002-07-31 (水) 01:16:28}
--インライン要素は多重ネストしますし、ブロック型プラグインの引数の中でも使用されます。したがってインライン要素をプラグイン化するには多重ネストを前提に設計する必要があります。 -- [[reimy]]
-<ほげほげ>と書く時には困らないですよ。文字参照や数字参照で対応できますから。[[ちょっと便利に]]参照。 -- [[reimy]] SIZE(10){2002-07-31 (水) 01:17:32}
--なかで書く場合は&lt;って書くってことですか? -- [[ゆう]] SIZE(10){2002-07-31 (水) 01:46:02}
--文字参照であればね -- [[reimy]] SIZE(10){2002-07-31 (水) 02:39:27}
--下のとこっちを僕がごっちゃにして書いたから、ブロック構造とブロック型は違うんだ話しになったともうんですが、インライン型にブロック構造を持たせると厄介なことになるなと思ったんです。これらの場合の処理が問題になりそうです。 -- [[ゆう]] SIZE(10){2002-07-31 (水) 11:54:39}
 &color(red) { &size(1) { 1red } } 単純なマッチングでは &color(red) { &size(1) { 1red }とマッチ
 &color(red) < &size(1) &lt; 1red &gt; > 書きづらい
 -lis &color(blue) {t1 複数行にまたがらせると訳がわからなくなる
  - list2 }
-文字参照とかの入力を強いるのはどうかと思います。でも文法が複雑になるとメタ文字のエスケープ手段を考えなくちゃいけないんですよね。難しい。 --  SIZE(10){2002-08-01 (木) 08:09:47}
-エスケープを強いるほうが問題あると思います。文字参照や数値参照は通常のHTMLでも使用するけど、エスケープはHTMLでは使いませんからね。エスケープを使うとパソコン初心者に敷居が高くなってしまいます。 -- [[reimy]] SIZE(10){2002-08-01 (木) 10:18:28}
-いや、< を &lt; で参照するってのは実質エスケープしているのと同じことです。それと、実体参照がパソコン初心者に優しいというのはものすごく疑問です。Wiki の中に HTML の概念である実体参照がはいってきちゃうのも気持ち悪くありません? --  SIZE(10){2002-08-01 (木) 10:34:41}
-僕も文字参照の方が難しいと思っています。 \>をみて>を想像するのは容易ですが、&gt;をみて>を想像は困難だと思います。 -- [[ゆう]] SIZE(10){2002-08-01 (木) 15:18:39}
--それは理系と文系の違い(笑い) -- [[reimy]]
--どっちが文系でどっちが理系ですか? HTMLを知らない人間が&lt;から<を連想するのは不可能だと思うんですけど?理系でも文系でも -- [[ゆう]] SIZE(10){2002-08-01 (木) 21:59:15}
--実体参照はHTMLだけのものじゃないです。SGML系統のほぼすべてのマークアップ言語で共通したものです。もちろんXMLも例外ではありません。-- [[reimy]]
--エスケープのほうがよっぽど知られてないですよ(少なくともプログラマ以外には)。-- [[reimy]]
--でもXMLもSGMLもほとんどの人は知らないと思います。それを抜きにして普通に考えて、\>から>を連想する方法と&gt;から>を連想するのどちらが簡単ですか? -- [[ゆう]] SIZE(10){2002-08-01 (木) 23:04:00}
--勘違いしてません? ユーザーが実体参照を入力するのではなく、すでにPukiWikiでは<は&lt;に、>は&gt;というように実体参照に変換されてます。なぜそのことが「文字参照とかの入力を強いる」ことなのでしょう? -- [[reimy]] SIZE(10){2002-08-01 (木) 18:34:33}
--上の方の議論で、<>の中で<>を使いたい場合は &lt; &gt; を使うとおっしゃられたからです。これはユーザの入力ですよね?
--それと、エスケープ == '\' って解釈もどうかと思いますけど。&lt; や &gt; や &amp; や &quot; はそもそもがエスケープのために実体参照にくわえられたものです。
-多分reimyさんとその他との議論が離れているとおもいます。まずHTMLのことは忘れてください。Wikiの文法はHTMLに縛られたものではありません。 ブロック構造を定義するものとして<>を使った場合、<A>という文字を赤で表示したい場合、&color(red)<<a>>という表記になるとおもいます。この場合中の<>は何らかの形でエスケープしてやらないと、通常パーサーは一つ目の>をブロック構造の終わりとみなしますから&color(red)のブロック構造引数は<aということになってしまいます。これを避けるには<a>をユーザが&lt;a&gt;と書くとか\<a\>と書いて&color(red)のブロック引数の終わりが一つ目の>のではないことを知らせてやる必要があります。OK? -- [[ゆう]] SIZE(10){2002-08-01 (木) 21:58:19}
-またインラインプラグインのネストをすることにしたんですか? よく方針が変わりますねぇ。朝令暮改? -- [[reimy]] SIZE(10){2002-08-01 (木) 22:56:28}
-まだ仕様決めなんだからいいんじゃないですか?両方ありえても<プラグインのネスト。それに上の問題とプラグインのネストには何も関係なんですが・・・・。 -- [[ゆう]] SIZE(10){2002-08-01 (木) 23:00:22}
-それにそういう書き方やめませんか?ここでは書き込んでいるひと以外のも複数の人が見ています。 -- [[ゆう]] SIZE(10){2002-08-01 (木) 23:15:24}
-自分でも[[BugTrack/104]]に「ただふつうの人にエスケープはわかりずらいよなー。 -- ゆう」って書いてるじゃないですか。これも朝令暮改? -- [[reimy]]
-引数の指定方法ですが、「ブロック構造である以上特殊な場合を除き必ず複数の引数がある」「値の法もそれなりにボリュームがある」「PukiWikiはほぼ行指向の文法である」訳ですから、、、 -- [[seagull]] SIZE(10){2002-08-02 (金) 13:02:32}
-「1行に1つの値」「空行が末尾(段落指定とあわせる)」「空のパラメータは許さない(必要な場合はなんらかの特殊記号をプラグインぐ側で定義」でいいように思いますけどね。 -- [[seagull]] SIZE(10){2002-08-02 (金) 13:04:31}
 #nekocomment
 うにゃにゃにゃ~ん (訳:さぁ、ブロック書式の始まりです)
  にゃにゃうにゃん   (訳:この下の空行でお終い)
 
 ってな感じ。  ←ここはすでに次の段落
うまいプラグインを作ると、パーサの切り替えみたいな動作を示すようになりそう
ですが。1行複数パラメータを許したい場合には表組みの構文が割と良くできていると
思うので、そういうのに合わせる形に持っていくと、複雑化を避けられるのでは?
-行単位の場合は良いんですけどSIZEみたいなのをプラグインにするときの引数が問題になっちゃうんですよー。 -- [[ゆう]] SIZE(10){2002-08-02 (金) 13:45:33}
-複数行のデータをプラグインに渡せるのならば、ソースコードを渡してハイライト処理して表示みたいなプラグインがつくれるって事ですよね?そういうのが一番需要が高いとおもうのですが、そういう記述が簡単ならいいなぁ、、、 -- [[jalopy]] &new{2004-02-08 (日) 22:43:44};
-[[PukiWiki/1.4/ちょっと便利に/複数行のプラグイン引数を可能に]] -- [[でぃあばぁ]] &new{2005-01-23 (日) 17:04:32};

#comment
//#comment

トップ   編集 差分 履歴 添付 複製 名前変更 リロード   新規 一覧 検索 最終更新   ヘルプ   最終更新のRSS
Site admin: PukiWiki Development Team

PukiWiki 1.5.4+ © 2001-2022 PukiWiki Development Team. Powered by PHP 8.2.12. HTML convert time: 0.043 sec.

SourceForge