時には過去や未来に飛びますが…
そういう訳で、京阪に乗ってみる。
Emacs 19 以降には site-lisp という場所があります。これは通常 ${PREFIX}/share/emacs/site-lisp/ にあります。また、Emacs 19.29 以降には、この他に ${PREFIX}/share/emacs/${VERSION}/site-lisp/ という version 固有の site-lisp があります。
ところで、apel/README.ja を書いたのは tomo じゃないらしいです。 maintainer もやめてしまったらしい。
ところで、どこから説明をするかってのは難しい問題だけど、多分、emacsen の初歩の説明まではできない気がする。Emacs の入門書じゃないから。また、 特に、directory 構成に関する事柄は Emacs 18/19.28 以前/19.29 以降/20.1 以降, XEmacs 20/21.1/21.2 以降で異なり、その詳細を説明することは難しいと思う。 （多分、詳しく書いたらかえって初心者には辛いと思う）
また、FreeBSD や各種 Linux distribution の類は独自の directory 構成を定め、そのために emacs をいじってたりすることがあるそうだけど、 そんなことまで elisp 作者の責任にされたらたまったものではない。
そこで、通常の GNU program からの類推が効くように書くというのが１次近似かなと思う。
多分、``run in-place'' と ``make install'' と書いてあればなんとなく image が湧くだろうし、PREFIX というのも類推できるだろう（だといいな (^_^;）。でもまあ、Emacs の load-path を説明するのは難しいな。 XEmacs の package system ならあんまり悩まなくても良いのだけど。
欲しいです。とりあえず、mail account が欲しいかなと思っていたんですが、 domain だともっとうれしいかも。（手元の machine を tomo.gr.jp 化できる）
やはり嫌われてしまったか？(;_;)
まあ、嫌われても仕方がないというか、これまでの自分の言動をふりかえると やっぱどっかおかしかった気はする。
無論、（少なくとも RFC 822 では）bare-CR は valid です。bare-LF も同様。
（某所における某記事を読んだ識者の多くは気づいていたようだ）
その筋の人はしばしば mget するものではあるのだが、一店買いというのはすさまじい。
お誕生日おめでとうございます。
左足の裏に激痛がはしる。原因不明。歩行困難。
まだ痛いが何とか歩いて職場にたどり着く。
夏休みダイヤらしい。竹田駅で待たされる。うぐぐ。
無論、（少なくとも RFC 822 では）bare-CR, bare-LF は field body でも valid です。
例えば、非構造化欄は「*text」なので、bare-CR, bare-LF が来ても構いません。即ち、Subject 欄には bare-CR, bare-LF が来ても構いません。
qtext や ctext, dtext も bare-LF が含まれますし、quoted-pair にすれば任意の US-ASCIIの文字を含むことができます。よって、 quoted-string や comment, domain-literal には bare-CR, bare-LF が来ても構いません。ということは、full name を書くような所だけでなく、 domain の中でさえ、bare-CR, bare-LF が来ても構わないということです。 comment は構造化欄のいたる所で使用可能ですから、結局、構造化欄でも bare-CR, bare-LF が来ても構わないということになります。
ところで、qtext, ctext, dtext で bare-CR を排除しているのに、bare-LF を排除してないのは何故なんでしょうね？字句解析の都合上なのかな？
確かに初心者には易しくないと思いますが 形式言語の知識があればそんなに難しくない気はします。
（某 x 師や akr 師の場合 むしろこういう形で記述した方が判りやすかったりして(^_^;;;）
確か、問題の本質は（文字符号ではなくて）character-indexing vs. byte-indexing なんだったと思う。info は point で管理されるので、 naive に実装すると、Emacs 20.1/20.2 では info file を coding-system で decode して Emacs の内部表現に変換した後、その Emacs の内部表現上での byte 位置で管理されることになる。一方、Emacs 19.34 以 前や Emacs 20.3 以降、XEmacs では文字単位に管理される。 よって、両者の間では 互いに読むことが可能な文字符号を使っていても info file の互換性は無いことになる。しかしながら、Emacs 20.3 以降? では手を加えて、Emacs 20.2 以前で作成した byte-indexing な info file も（ある程度）読めるようにしてある。
結論として、次のことが言える：
us-ascii の info file は全ての emacsen で読める。
iso-8859-1 で符号化した info file の場合、Emacs 20.1/20.2 で作成したものは Emacs 20.3 以降でも読めるが、Emacs 19.34 以前や XEmacs では読めないと考えられる。また、Emacs 19.34 以前や XEmacs で作成したものは Emacs 20.1/20.2 では読めないと考えられる。
それ以外の符号のものは 互いにその符号が読めるとして、Emacs 20.1/20.2 で作成したものは Emacs 20.3 以降でも読めるが、XEmacs では読めないと考えられる。また、XEmacs で作成したものは Emacs 20.1/20.2 では読めないと考えられる。
そういう訳で、最新の emacsen は全て character-indexing なので、info file を共有することができる。
ところで、Emacs 20.1/20.2 の info file と 20.3 以降の info file の両者を比較すれば、後者が文字概念を仮定すれば良いだけであるのに対し、 前者は Emacs 20.1/20.2 での Emacs の内部表現を仮定せざるを得ず、明らか に後者の方が優れているといえる（というか、前者は論外。外部の info viewer とかのことを考えてないとしか言いようがない）。
我が母校、城内に 7 対 1 で敗れるも、9 回やったので 9 人しかいないチームにしては上出来だと言えよう。
一方、天理が上牧に敗れるという波乱も。
智弁、郡山はまだ残っている。智弁優勝だと悲しいかも（津邑さん ごめんなさい。あ、でも、和歌山じゃないから OK か？）
城内、香芝に敗れる。
郡山は斑鳩を５回コールドで下す。これで 家から歩いて行ける場所に存在する高校は郡山のみとなった （郡山、城内とも郡山城跡にある）。
智弁も片桐を下している。
茶尾に逆襲される。痛い。
相変わらず痛い。
という訳で、変えてみました。
なお、猫頭氏の日記は始まっていないようです。でも、tomo の日記は比較的 最近な今日この頃。
いつもの調子だったんやな。(^_^;
ちなみに、おっちゃんが行くことになったのは、前回出席した方が、いつもは しゃんしゃん可決なのに、前回の審議が超白熱したのに嫌気がさして、 『専門家』であるはずの おっちゃんに出席を依頼したからだったと聞いた気がする。
で、おっちゃんは「おとしちゃおう」とか言ったので、それじゃ使えんなどと 一所懸命説得した記憶があるが、あんまり説得されてなかったらしい。:-P
とはいえ、工技院的にはこの段階で落ちてしまうのは困るので、 通ること自体は概ね決まっていたようだけども。
でまあ、皆さんが BMP への収録を目指した結果、m17n-2000 で紹介された 例の『フィンランドの少数民族』の逆襲があったりする訳だが、結局、 これらの試みは成功しなかったのはご存知の通り。
もっとも、CCS が気になる人にとってもっとも重大な問題は、一部の文字が BMP に収録されなかったことではなくて、BMP に変な形で収録されたことにある。
例えば、<LATIN SMALL LETTER ALPHA> に <COMBINING ACUTE ACCENT> を付けた発音記号用ラテン文字を 既に存在するギリシア文字に写像したりとか。こうしてしまうと、JIS X 0213 の世界と UCS の世界で script や文字結合が一致しなくなる。あるいは、JIS X 0213 で使用制限されていない新しい漢字を UCS の互換漢字に写像するのも問題である。さらにのたうってしまうのが、JIS X 0213 第１面の #x7D5D のような例である。この字は U+9686 の中国、台湾、 韓国出典字形と同じ字体であるが、互換漢字の U+F9DC に写像している。この 結果、JIS X 0213 第１面の #x7D5D のような字体を符号化する時、GB, CNS, KS mapping を行った時は U+9686 になり、JIS mapping を行った時は U+F9DC になるという困った事態になる。既存の JIS X 0208 mapping を変更したくないという理由に依るのだろうが、困ったことである。まあ、 包摂規準を変更しているので仕方が無いのではあるが。ついでにいえば、 Extension-C では事実上 包摂規準が変わってしまうらしいので、もっと本格的に 困った事態が起こるそうだが。もっとも、ISO/IEC 10646-2 でも十分に困ったことになりそうだけども。いずれにしても、JIS X 0213 は Unicode を壊しにかかっている（by 安岡さん）という側面は否めない。
わりかしどうでも良い話だが、経済産業省に残るのは標準関係だけで、 その他は独立行政法人になるはず。
なんとなく、小形さんは認識してない気がするが、 現在の工業技術院の大部分は研究機関で、 電総研も工業技術院の中の１つの研究所である。
こむらがえりの激痛で目が覚める。ベッドの上でのたうち回るが、 茶尾は足元でのうのうと寝ている。変な歩き方を続けているせいか？
link 可也。然れども「勤め先」への link は喜ばしからず。亦 夫れ「付属」にあらず。
鈴木先生、 「APEL, FLIM, SEMI, WEMI, EMH, RMAIL-MIME 私家版インストールマニュアル」 などはいかがでしょうか？また、site-lisp のことは御理解頂けたでしょうか？
それにしてもe漢字の関係者はどこにいるのだろうか？京都大学 人文科学研究所にいないことだけは確かだが:-P