アカウント名:
パスワード:
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」というふうには、割り切れんもんなのでしょうか?
見落としているかもしれませんが、レイアウトというのは貴重な情報源です。適切なレイアウトはデータを整理し、人間の理解を助けます。そもそも、人間が表現を行うときには、本質的にデータとレイアウトの両方を含んでいます。ただ、そのままではmachine readabilityが低いので、ここ数年来、データとレイアウトを分離する必要性が認知され実践されてきました。
しかし、分離したとき
#たぶん全部というのかなぁ? もしこれらすべてというのであれば、同じレンダ
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
人生の大半の問題はスルー力で解決する -- スルー力研究専門家
ところで (スコア:1, 興味深い)
文字ピッチの問題をどうやって解決すればいいんでしょうか。
たとえば、英語端末では歴史的に固定ピッチフォントでないと困りますし、
日本語端末だと歴史的に漢字は ANK の倍の幅をもってないといろいろ困ったことになったりしますけど、
エスニックな文字ではその辺はどうなってるんでしょう?
前から多言語な端末作
Re: ところで (スコア:1)
> 英語端末では歴史的に固定ピッチフォントでないと困りますし、
しばらく9termを使った経験からいうと、端末がプロポーショナルフォントでもあんまり困らないと思います。困るのはせいぜい、アスキーアートを見る時くらいじゃないでしょうか。
Re: ところで (スコア:1)
Re: ところで (スコア:1)
# で、タブの定義は? :-)
Re: ところで (スコア:1)
繁雑にはなるけど、パーズは楽になる、、、はず、、。
#XMLの適用って、どんなデータまで妥当?
スペースの次はタブ (スコア:1)
なんだかんだ言って、初めてスクリーンエディタができた頃からごく最近まで、 アルファベットと数字だけ使えればよかった時代は幸運だったし幸福だったと 思う。全ての文字が同じ大きさだったおかげで、印字内容とレイアウトという 異なる概念がでそのまんま具現できたから。そのおかげでテキストエディタっ てのは最初の時代から今まで使えるずっと便利なWYSWYG環境だったわけで。
Re:スペースの次はタブ (スコア:1)
>たとえ ば JavaML [washington.edu] なんてものもあるけど、そのソースを手で
>こう [washington.edu]書くなんて気が狂うでしょ。
それぐらいは、書けんことはないですよぉ。それって、別にテキストじゃなくてプログラムローダーを書いているわけですから。
>テキストエディ タでスペースバーを叩いてレイアウト決めてたのに比べればどれだけ大変か。
それは同意。でも、「レイアウトなんて情報交換には無駄無駄。押し着せのレイアウトで十分」とい
Re:スペースの次はタブ (スコア:1)
見落としているかもしれませんが、レイアウトというのは貴重な情報源です。適切なレイアウトはデータを整理し、人間の理解を助けます。そもそも、人間が表現を行うときには、本質的にデータとレイアウトの両方を含んでいます。ただ、そのままではmachine readabilityが低いので、ここ数年来、データとレイアウトを分離する必要性が認知され実践されてきました。
しかし、分離したとき
Re:スペースの次はタブ (スコア:1)
これ↓以前のところは同意。
>しかし、分離したときに、人間の自然な表現に含まれていたはずのレイアウトは
>どこに行くのでしょう?
さて、このあたりからちょっと立場が違うようです。さっきの乱暴な聞き方じゃなくて、もう少しブレークダウンします。文書はどこまでオリジナルに忠実であるべきだと思いますか?
#たぶん全部というのかなぁ?
もしこれらすべてというのであれば、同じレンダ
Re:スペースの次はタブ (スコア:1)
machine-machine interfaceはどんな形式でも構いません。統一されるのはよ いことなのでXMLでOKです。
しかし、私は最初から今までhuman-machine interfaceの話をしています。 human-machine interfaceはend pointなので、どんな形式に変換してもよいし、 その際には人間のニーズにとって、より直感的で便利な形式を採るのがよいで しょう。
具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。プログラムのソースもhuman-machine
Re:スペースの次はタブ (スコア:1)
>具体的な例として挙げて来たのが、ターミナルエミュレータ(たとえば今回の mlterm)に
>表示される情報をCやPerlの中に埋め込む時に、よいインタフェース は何か? ということです。
>プログラムのソースもhuman-machine interfaceの一つ ですよね。
それが論点の中心であれば、私の意見は「XML吐くだけならフレームワークというか、ライブラリと言うか、それを補助するものを使えばいいんじゃないかなぁ?」です。でもnasbさんの本論は「そのような所でも表現の余地を残したい」でしたっけ。そうすると、、、
Re:スペースの次はタブ (スコア:1)
#ストカ臭い?