vieweditattachhistoryswikistopchangessearchhelp

Wiki の書き込みの書式はどんなのがいい？

ここからの続き

＞いいのが思い浮かばない…。
っても、Swiki はページタイトルが気ままに変えられるから実害は少ないかも。--sumim

いろいろと考えられますけど、ツリーの良い点（よく使われる理由）は見栄えの賛否はともかく、階層をかなり簡単に、つまり先頭の - の数だけで調節できることにあると思います。HTML タグが使える Swiki においては Swiki のジェネレータが生成する HTML ソースとコンフリクトしない限りかなり自由なレイアウトができるのですが、それでもレイアウトを意識しての書き込みははっきり言って面倒です。思い付いたままさくっと書きたいですもんね。だから字下げの代替はそれに匹敵するくらい簡単でしかも、後から見ても見やすいもの（時系列とスレッドを同時に追えるもの）でなければいけないわけですが、これがなかなかいいのが思い付かない…のは戯さんと一緒です(^_^;)。--sumim

見やすいか使いやすいかどうかは別にして、うまい差分メソッドが書ければ（現行のままだとラフすぎてだめ）、加筆修正した部分だけ IP ごとに色分けしてゆく…なんてのをテストしてみたいなぁ…とは思うのですが、なかなか。--sumim

箇条書きの好きな人は書きやすいから好き。嫌いな人は読みにくいから嫌い。
すっぱり分かれますね。僕は個人的には嫌いです。--SHIMADA

箇条と字下げはまた微妙に違う問題かも。
差分については、以前スラドでも紹介された、1ページしかないWikiみたいな(笑)サイトが
文字単位の差分表示を実現してましたね。あれどうやるのかなあ？ -戯

言葉が足りず誤読させてしまったようですが、箇条書きという言葉で表現したかったのはOL-LIの字下げをどんどんネストしてリアス式海岸みたいになっちゃったWikiページのことです。--SHIMADA

言葉が足りなかったわけじゃなく(「言葉が足りない」という言い回しは誤用されることが多いような気がする)、言葉が違っていたのでしょうね。

リアス式で笑えました。うねりコードって奴ですかね(^^; - 2003-03-04, 19:19:07

リアスもといツリー構造について仮説を1つ。
ツリー自体には自己説明能力は殆ど無いのではないかな？

だから、既に書かれたツリーに自分の文を挿入させたくなっても、「どこにどう入ってよい」のやら読み取れない、のかも？

これは、一部で忌み嫌われてる(笑)「行間」と、本質は同じなのかも。
それこそツリー構造そのものは行間と物理的にもソックリなわけだが、
意味的にも、そのツリーの形が「何を意味している」のかは一般には判然としないわけで、
にも関わらずそれは人様の目前に堂々と鎮座しているわけで…

う。これは俺もツリーを嫌わないと駄目なのか？なのか？(藁 - 2003-03-15, 02:41:50

いろいろと整理していて、発言は原則、要所にベタで（字下げをせずに）書いていって、- による字下げはメールなどでの # 的（余談やコメントだが本来はそこからの話題の派生を嫌う意思表示）に使うと、“あとから来て読みやすく当事者も書きやすい”かもと思い始めました。しばらくこの仮説に従って編集してみます。字下げに関しては、したがって、自分だけがそれを受けることができて、## とか ### にしてゆくのを字下げ（-- 、--- 、……）に対応させる。他の人はそこに割り込んでのコメントは差し控え、あるいは、敢えてそこから話題を派生させたいなら、字下げをせずに新しいページを作るか、引用してコメントをすると。こんなんでどうでしょうね。--sumim

うーむ。「派生を嫌う」ことは悪の枢軸だと俺は思っていまして…(^^;
publicな(Read And Writeが世間へ公開されてる)場において、
人の突っ込みを拒絶するってのは、人として(ぉ)あるまじきことだと思っています。
任意の(Privacy侵害などのごく一部の問題はともかくとして)突っ込みが嫌なら、最初から何も書くな、と。--戯

「派生を“嫌う”」という言い回しには語弊がありましたね。この Swiki における - の使い方とからめた話に限って言えば「ここに書いたことは余談、ささいな追記事項、ひとりごとのたぐいなので、これを受けて何かを書くことはすなわち話題の派生にあたるため、別スレッド（別表題、別 WikiName、別項、などなど）を設けた方がよさそうですよという書き手の意思表示（ただしその判断の是非は別）」というふうに言い直させてください。--sumim

ツリー構造について思いついたんだけど、もしや、
デザインパターンのテンプレートメソッドパターンは、書くのは楽だが読み解くのは難しい、
ってことになるんだろうか？ -戯

もしかしてツリー構造は正規表現みたいなものなんでしょうか？
つまり、構造化プログラミングで書いたような意味での「関数化」を、やらない世界。

そうだとすると、確かに記述受容力に(あまり高くない)限界が有るよなあ。

そういう意味では、突っ込み機能つきのHashedWikiは凄かった。
まさに(関数とかと同じ意味での)参照を記述できる世界だったのだから。

なお、巷の掲示板(やココ)でよく行われている「引用」は、
だいたいが参照(ただし点への参照じゃなく長さを持った文字列への参照だが)の代用品でしかない
という意味で、ちょっとショッパイ。 --戯


＞文字単位の差分表示を実現
IMHO で、オブジェクト“思考”的には(^_^;)、文字ごとにどの IP アドレスからの書き込みによるものかを知っていて、表示時に自分の色を決める…ってのを一回つくってみたいもので。アラン・ケイがデモしていた文字ごとがオブジェクト（まあ morph なんですが）で自己組織的に自動改行するやつなんかみたいだとおもしろいかなぁ…って。--sumim - 2003-03-04, 10:25:00

なるほど。文字(ってのか)が、自らがいつどこでどんな経緯で作られて、隣人はどれで、とかいった情報を知っているんですね。ViewとしてFont(?)を参照する。
今のPCの馬鹿みたいに大量なリソースは、そういうお洒落な贅沢のために費やさないと、バチが当たりますよね(^^; -戯

つらつらと考えるに、下の“貧相なテキスト編集環境”延命の元凶を作ったのは Smalltalk（できるのにやらなかった）、もしくは Alto の非力さ（できるけどやれなかった）だったかもしれませんね。今のマシンパワーなら、無茶苦茶遅くともせいぜい昔の Alto で動いていた程度のスピードで、文字もどきをオブジェクトとした自己組織的テキスト編集環境（自分たちの手持ちの情報で履歴作成や復帰、必要なら HTML 出力などをメッセージを受けて行なう。あるいはこうした文字もどきの生育環境）としてのワープロやエディタを作れるかも、と。暇になったらチャレンジかな。--sumim - 2003-03-05, 10:46:32



ところで、それと真っ向から敵対するのが、今の多くの貧相なTextEdit環境。
つまり、例えばある2文字を「入れ替え」たとしたら、それが入れ替えだったかどうかという情報は、貧相なEditorでは捨てられてしまう。
そしてディスクやNetの向こうにSaveした瞬間に、全ての証拠は失われてしまう。
古典的なdiffが野蛮である所以です(実際しばしば変な挙動をするし)。さてどうしよう…

情報を失うテキスト編集環境の話を伺っていると、本職にちょっと関わる分子遺伝学とのアナロジーに思い至ります。ＤＮＡの遺伝暗号は残念ながら先に想定したような機能を有するオブジェクトでないので、まさに貧相なテキスト編集環境の文字のように編集過程情報をどんどん捨てていってしまうのですね。ですから、分子遺伝学的作業は、十人が自分の感性で貧相なテキスト編集環境”を使って編集した文面に基づき元の文章を予測する…というようなかなり無茶な作業になります。--sumim - 2003-03-05, 10:52:10

todo.org:テクニカルWikiの履歴参照/diffの段階的適用 と話題が似てきた？ --戯 - 2003-03-09, 13:06:52


このページを編集 (7707 bytes)

Congratulations! 以下の 1 ページから参照されています。

This page has been visited 5991 times.