アカウント名:
パスワード:
TeX のソースはテキストファイルだから、必要に応じて様々なツールを援用できるけど、ワープロは (基本的に) 独自ファイルだから、ワープロソフトに機能をつめこんでおく必要がありますね。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
使うかといわれればびみょー (スコア:1, すばらしい洞察)
Re:使うかといわれればびみょー (スコア:0)
TeX のソースはテキストファイルだから、必要に応じて様々なツールを援用できるけど、ワープロは (基本的に) 独自ファイルだから、ワープロソフトに機能をつめこんでおく必要がありますね。
Re:使うかといわれればびみょー (スコア:1)
今回の話と関係あるかどうかは微妙ですが、一応。
「ファイル(形式)が」独自だからといって、「1つの」アプリ(ワープロ)に機能を詰め込む必要は、
あるとは限りません。
だって、複数のアプリ(やライブラリやプラグイン)が同一のファイル形式をサポートしてれば済むんだもん。
しょせんはUnixのテキスト文化も、「プレーンテキスト」という特定の(^^;フォーマットに
全てのプログラムが特化してる、というだけのことなんだよね。
まあ、他のフォーマットの更に基盤となるという「メタフォーマット」的な機能が
期待しやすいという意味では、テキストファイルは便利だけど。
#テキストの背中にXMLを乗せてーー、XMLの背中にSVGを乗せてーー、の3階層とか。
閑話休題。ファイル形式の「サポート」ってのは、結局は、
ある機能(アプリとかライブラリとか)が使ってる「ファイル解釈器」が
その形式のための解釈器であれば、それでいいんですよね。
解釈器は、テキストファイルならばgets()だし(藁)、XMLならDOMだかSAXだか(の実装)だろうし、と。
で、解釈器だと考えると、フォーマットは個々の機能(アプリとか)に専用化するよりも、
むしろ階層を細かくわけて、個々の階層は出来るだけ難しくない解釈だけを行なうようにして、
そして多くの機能が1つの解釈器(や解釈器グループ)を共有し使いまわす、というかたちにするほうが
便利そうです。少なくともプログラムの生産性という意味では。
#XML解釈器とS式解釈器は手元に置いておいたほうがいい…のかな…なのでG7
----
余談:
WindowsのExplorerで、「ファイル内文字列の検索」機能を、上記の発想で実装しててくれたらよかったのにな。
解釈器は個々のアプリ(?)が持ってる、と捉えて、
各種のデータフォーマットの中身にご所望の文字列があるかどうかを、そのアプリに探索「させる」、ってこと。
PNGを見るツールが、PNGの中の文字列をOCR(?)で拾い上げて検索する、という機能を提供してくれるとかさ。
遅いだろうけど、速度はここでは問題ではないです。
拡張子連動設定に「Run」とかだけじゃなく「FindString」っていうアクションも存在してくれれば
よかったのかも。