//beginchild, //endchildを使った自動判定による箇条書き子要素指示

[kmuto]

#1492 からの変形版

• //beginchild〜//endchildの対にした。名前はもうちょっと考えたほうがいいか？ 複雑になると構造がわかりにくい感じ。挙動としては無意味でもメモ用に引数をとるようにする？
• Compilerでは箇条書きが終わったらビルダの@previous_last_typeに箇条書きの種類名を入れる。ただ、この変数をnilにするタイミングがないので、1回箇条書きを使いさえすれば以降のどこでも意図しない構造が作れてしまう。

↓

• //beginchild、//endchild は0個または1個のオプションを取れるようにした。オプションはコメント用(たとえば//beginchild[番号箇条書き内始め])で、挙動には影響しない。
• //begin,//endの対応関係を見るようにしているので、いちおう「意図しない構造」は発生しづらいと思う。

[takahashim]

とりあえずconflictしていたのを修正しました。

[kmuto]

ありがとうございます!

[kmuto]

@takahashim
ブロック要素のほうは入れ子できるようにするとして、箇条書きのほうはあまりどうにもならない気がするので、結局こういう前後指示命令を入れていくぶん無理矢理対処するしかないのではと思います。

実験的にでも入れることは禍根になりそうでしょうかね…。ただ暗黙記法は増やしたくないし、インデントでの区別は嫌だし、箇条書きの性質的に//{なものも使えないですし。

[takahashim]

これですが、あまり綺麗な構文が思いつかないので（冗長に書いてもいいならブロックの入れ子で表現できそうですが、現状の箇条書きに比べると圧倒的に見通しが悪そう）、将来的に廃止することになった場合壊れても構わないのであれば入れても良いかも、と思いました。

[takahashim]

あー、でもコメントを取る機能はやめた方がいいかも、と思いました。他の記法と異なりすぎるので（コメント以外に使いたくなっても困るし）。

[kmuto]

なるほど、了解です。まぁ#@#でも入れとけという話ですしね。

[kmuto]

なんとなくconflictが出そうな気がするので、#1558 の後にマージしようかと思います。
macOSビルドはハイライトテストのところでなんか変ですね。たまにrougeかpygmentsの結果が一致しないことがありますな…。

[takahashim]

conflict解消してみました