Emacs part 18

2006/03/02(木) 23:19:32

Emacs環境について語れ

GNU Emacs - GNU Project - Free Software Foundation (FSF)
http://www.gnu.org/software/emacs/

emacs - SCM: CVS Repositories [Savannah]
http://savannah.gnu.org/cvs/?group=emacs

EmacsWiki
http://www.emacswiki.org/

Emacs 電子書棚
http://www.bookshelf.jp/

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 01:02:21

>>496
fork しようよ。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 01:07:55

スクリプト言語を使って高速な数値計算するときはスクリプトでループを回してはいけないのが常識だが、
Emacsにもそれを適用してみるのはどうだろう？
探索や置換をprimitiveにするとそこそこ高速になると思う。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 01:09:23

forkしたらしたで本家との非互換性が出てきて動かないEmacsLispが出てきたりとかするのが困る。
xemacsなんてたとえてみればアミバ流北斗神拳だろ。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 01:11:49

バッファにたいしてGNU grepのアリゴリズム使えないのかな…

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 01:14:20

>>500
> アリゴリズム

**500** · 2006/04/11(火) 01:15:19

しまった、typoしてしもうたorz

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 10:45:30

>>496
日本人の最大の欠点。
英語で議論できない。

パッチだけ送って取り込まれないとごねる。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 13:10:30

英語を母国語にしていてもあのrmsを説得するのは至難の業だと思うが

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 13:55:17

日本人だからと決め付けるのはとんだ偏見ですね

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 14:18:10

mule入ったやん
rmsは始めごねてたのに

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 14:55:35

最初ごねるのはしょうがない。彼等にとって他言語などどーでもいいのだから。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 18:22:12

以前、GNU Lightning を使ってバイトコードをネイティブコードに
コンパイルするというパッチが送られてきたときは

http://lists.gnu.org/archive/html/emacs-devel/2004-03/msg00469.html
I don't think that a speedup of less than a factor of 2 would be worth
installing something that might take substantial maintenance effort.

いきなりこれ。で、パッチ作者ががんばって効率化したら

http://lists.gnu.org/archive/html/emacs-devel/2004-06/msg00103.html
I simply deleted that TODO entry, since it looks like this optimization
isn't worth a big effort. Computers are so fast nowadays that Emacs
Lisp code hardly needs speeding up.

ということで終了だもん。途中で言ってること変えるんだから議論のしようがない。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 18:29:25

だめぽ

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 18:48:11

別に変わってないだろ、2倍より速くなったら入れると確約したわけじゃあるまいし。
俺自身も遅いマシンでベイジアンフィルタつきnavi2chで見るために
バイトコードをx86のネイティブコードに変換するのを自分で実装して
一時期使ってたりしたけどさ。
それ自体は仕事としては、あまり前向きな仕事じゃないんだよ。
どうせ真面目に高速化を考えてもっていこうとすると今のelispをそのまま扱う
んじゃなくなるだろうから、かなりのreworkというかやり直しになるんだし。

メールを見るに、そのパッチを投げた人もそのへんわかってるんじゃないかと思うけど。
自分では何もしない人から見ると面白そうだけど、
やってみればその仕事の価値というか位置付けみたいなものは自分でわかる。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:05:00

結局Emacsアプリはもっと外部コマンド指向にしろってこったな。
rmsはEmacsLispを高速化する気さらさらないんだから。
navi2chもpure elispだなんて愚かな設計だよ。
誰かEmacsで動く高速な2chブラウザ開発してないかね。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:07:22

その点Mewはいい設計だと思う。
EmacsLispが遅いことを知っているからこそ時間のかかる処理を外部コマンドにやらせている。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:10:26

一般的に、開発が進むと、外部コマンドで行なっていた処理を
どんどん内部化するという傾向があるように思うのだけど、
あれはどういう理由なの?

バックエンドを作っておけばいろいろなインターフェースから使えるから、
外部コマンドを使うというのは大変良い解法のように思えるのだけど。

何か問題があるの?

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:13:29

具体例をもってきた方が話しやすいと思う。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:13:34

>>513に激しく同意だ。
ユーザに外部コマンドをインストールさせるのが面倒だとか考えてんじゃないの？
ユーザとしては動作が遅くなる方が大問題なんだけど。
emacs-w3mもnavi2chもソース見てて痛々しいんだよな。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:17:04

結局のところ、EmacsLispは計算処理をするのが苦手で直す気ないんだから、
計算処理は外部コマンド、入出力、表示のみEmacsLispというのが最適解なんだろうね。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 19:48:09

>>512
mewは確かに、
mewencode, mewl, incm, mewstunnelを持っているけど、
昔に比べると徐々にelispを使う方向になってきている。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:10:40

まじかよorz
なんか1.xx時代はとても速かったのに。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:21:24

>>517
IMがmewのバックエンドだった。

**517** · 2006/04/11(火) 20:26:35

昔は、
$ imls +フォルダ名 > ~/Mail/フォルダ名/.mew-cache
ってやってた。万単位のメールあるところで。

今は全部elispで書けるから、設定の自由度上がったけれど、遅いね。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:31:21

わざわざEmacsLisp化して遅くするなんて正気の沙汰とは思えんね。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:52:56

いろんなプラットフォームで動く外部コマンド書くのもつらくない？

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:54:02

>>522
> いろんなプラットフォームで動く外部コマンド書くのもつらくない？

Perl/Rubyでいっぱつ。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 20:55:57

そういや、設定/カスタマイズ関係が厄介という問題があったねえ。
まあ、なんらかの標準化や翻訳メカニズムを作ってしまえば、それで
行けるのだろうけど。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 21:35:15

>>523
べつにCでもいいじゃん。小規模のものなら誰かが移植してくれる。
>>524
それはひとえに設計が悪いからじゃないのか？
EmacsLispでオプションを設定してコマンドラインで渡せばいいだろ。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 23:36:33

ELisp で書いてあると、各種 hook とか advice とかでいじりやすい。
昨今の強力なマシンなら Emacs だけで処理してもなんとかなるし。
速さより手軽にいじれることのが重要になってくんでしょ、きっと。

**名無しさん＠お腹いっぱい。** · 2006/04/11(火) 23:53:21

>>512
MewはMH-Eの代替品だからああいう形になっているのかと思っていた。
そういえば、最近のMewのInfoからはMH-Eの悪口消えたのね。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 00:42:42

>>515
emacs-w3mはw3の二の舞になってるね。

>>526
EmacsLispが増えるとその反面、全体像が見えづらくなってカスタマイズが困難だけど。
いっそのことEmacsLispを1000行前後に抑えてあとは全部外部コマンドまかせにしてくれ。

>>527
なつかしい、俺がLinux駆け出しだったころ悪口書いてあったな。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 00:47:19

>>526
Pen4の3GHzだけど遅く感じることがあるんだけど。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 00:48:24

そもそもemacsをCに「移植」しようという試みは過去に何度あったのでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 00:49:50

はぁ？もともとCで書かれてるだろうが。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:30:08

lisp 部分が遅いのはダイナミックスコープと関係ある？

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:36:57

vimはほとんどCで実装されていて高機能な割に高速なエディターだけど、
ソースはとんでもなく読み辛くて汚い。

Emacsをソースから入れている人は、知らない関数とかをhelpで調べて、
そっからlisp、Cに限らずソースに直接飛んだりしてると思うけど、
vimとかそれが出来ないんだよ？

どんなに単純そうな処理ですら、キーを押した後なにが起きてるのか
わからんのは、どうかと思うよ。

外部コマンドなんかにしたら、なおさらブラックボックス化してくよ。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:42:38

いろんなプラットホームで使ってると、
外部コマンドに依存するのはいやだなぁ。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:44:03

なぜ？

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:52:57

EmacsLispは遅いんだから結局外部コマンドに頼るしかないのが現状なんだよ。
rmsは高速化する気まったくないようだから。
インストールが面倒とか言う厨房はかえれ。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 01:55:47

まあまあ、議論して結論を出そうとしてもしょうがないのだから。
「主張して実践する」ことで示すしかないのだし。

ここはそれぞれの方法の利点欠点をリストアップして、
インプリメントの一助にするのが建設的。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 02:08:50

>>487
も言ってるけど、primitive不足ってのが最大の理由だろう。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 02:25:50

しかし、開発陣はそれを認めようとしないんだよね
かといってdynamic linkも本家に取り込んでくれない
だから高速化したければ外部プロセスに追い出すのが現実的

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 02:30:40

Rubyは実行速度の遅さを拡張ライブラリでカバーしているからこそ成功している。
Emacsもそうしてもらいたいものだね。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 07:15:40

確かに e-lisp が遅いと感じる人もいるだろうし、
外部プロセスに渡して幸せになりたいのも判るけど、
自分は現状で満足な訳で。

まぁつまり、ぐだぐだ言うより外部プロセスをかっこよく使って
高速に動くソフトをいっぱい書いて布教した方が建設的じゃね?

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 08:12:26

>>541
> 高速に動くソフトをいっぱい書いて布教した方が建設的じゃね?

そうしましょう、そうしましょう。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 08:46:25

>>515
痛々しい箇所の具体例きぼん

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 15:51:16

>>543
多すぎて書ききれない。
テキスト処理を黙々とやらせてるところ。
EmacsLispはテキスト処理苦手なんだってば。

3GHzマシンなのにnavi2chでスレを開くとき10秒前後待たされる。
emacswikiのindexを開くのに何十秒も待たされる。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 15:53:42

全部挙げろとは誰も言ってないから多すぎても別に困らんでしょ。
多すぎるならためしに2つ3つ挙げてみてよ。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 17:30:03

Meadow（emacs21.4)でshell-command-on-regionの文字化けにつき
困っております。
utf-8のファイルの一部にperl（cygwin）のコマンドをかけて
整形したいのですが、perlスクリプト自体は、正常にutf-8の
コードを吐きますので問題ないはずなのに、emacsのバッファには
こんな変な文字が出ちゃいます。

1. 壤壤壤｢壤｢↓壤壤壤｢壤｢∂壤壤壤｢壤｢∀壤壤壤｢壤ｶ∪壤壤壤｢壤ｳ� 壤壤壤｢壤｣E壤壤壤｢壤｣B壤壤壤｢壤｡[壤壤壤｢壤｣壤壤壤｢壤ｳ壤壤壤｢壤｢∇懼ｬﾀ壤壤壤｢壤ｭs壤壤壤｢壤｢�壤壤壤｢壤｢⇔壤壤壤｢壤｡H

文字コード関係の設定を変えてるんですが、どうも臭いと思われる
以下の2番目の奴を変更する関数がないようです。
set-buffer-file-coding-system
だと一番目のしか変わらないのですが、何で変えられるのでしょうか。

Coding system for saving this buffer:
u -- utf-8-dos
Default coding system (for new files):
S -- japanese-shift-jis-dos

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 19:23:38

set-default-coding-systems

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 19:25:33

set-process-coding-system

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 19:41:31

C-x RET c

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 20:52:55

>>545
馬鹿を追い詰めなさんな。

**546** · 2006/04/12(水) 21:48:55

>>547-549
ありがとうございます。
set-default-coding-systemって、version21にはないようです。
以前はあったのは知ってます。(19だったか20）
set-buffer-process-coding-systemやると、outputのコードを
聞かれてutf-8とやるまではいいのですが、inputのをutf-8で
答えると、no processとかのメッセージが帰ってくる。
無視してやってみるも、やはり>>546みたいに文字化けします。
さんざんググりもしましたが情報がないので、たぶん、
cygwin、Meadowという環境では無理なのかとも思っています。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 21:54:42

GNU Emacs 21.4ならあるけど

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 21:55:15

意見を述べた人を馬鹿呼ばわりとは、しょせん2chか

**546** · 2006/04/12(水) 22:02:24

>>552
Meadow固有ですかね。こんな作りのネットインストール版です。
GNU Emacs 21.4.1 (i386-mingw-nt5.1.2600) of 2005-08-28 on CUBE

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 22:09:00

lispの下探ってみろよ。

**名無しさん＠お腹いっぱい。** · 2006/04/12(水) 22:56:52

M-x apropos set.+coding-system
してみろ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 01:24:07

>>546
俺なら、
shell-command-on-region で、リダイレクトしちゃって、
delete-region
insert-file
で逃げる。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 02:11:30

flymakeとか、文法チェックまで外部プロセスに追い出してるね。
Cのようなマクロを含む言語はelispでパースしきれないから、このアプローチも頷ける。

動かすの少々大変だけど、誰か改良してくれないかな。

**546** · 2006/04/13(木) 03:03:36

>>555
私に言ってるんですよね、どうもです。
grepしたら、
/cygdrive/d/Meadow/lisp$ grep set-default-coding-system language/*.el
language/japan-util.el: (set-default-coding-systems 'japanese-shift-jis-dos)
こんなんあったんで、.emacsに、(require 'japan-util)って書いて
再起動してやってみたんですが、だめでした。

**546** · 2006/04/13(木) 03:39:07

>>556
ありがとうございます。
M-xで出てこないようなコマンドは.emacsで設定しなければいけないんですか。
>>557
やってみたんですが、ファイル自体はちゃんとutf-8でできてるんですが、
insertすると日本語はいいんですがlat-1の文字が変な文字になっちゃいます。
それで、after-insert-file-set-buffer-file-coding-systemら辺だろうと
思うのですが、M-xでその関数は呼べない。.emacsに設定すると（まだ
やってみてないんですが）、普段もutf-8ばっかり使わなきゃならなくなるの
も困るんです。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 04:18:34

M-xで呼べない関数は内部利用のための関数だ。
その程度の常識すらわからないんだったら、あきらめろ。
今のおまいに多言語を扱うのははやすぎる。
常識から勉強するこったな。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 04:31:51

>>516 には基本的に同意するけど、
emacs ユーザは elisp の構造が理解できてて当たり前ってのも
すごい常識だよな。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 04:40:49

interactiveな関数しかM-xで呼べないなんてEmacs使いの間では常識でしょ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 05:35:01

そもそもEmacsは玄人向けのツール。Emacsユーザにとってemacs-lispの初歩な
ど一般教養レベル。自分から学ぼうとする気のない人が使うべきものではない。
そういう人はワードかメモ帳でも使ってなさいな。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 05:46:30

>>558
> Cのようなマクロを含む言語はelispでパースしきれないから、このアプローチも頷ける。

そんなことはないだろ。elispだってプログラミング言語だ。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 06:40:11

だが、遅い！遅すぎるー！！

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 06:49:11

>>566
> だが、遅い！遅すぎるー！！

そうだな。
でもわめいても速くならないぞ。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 06:56:19

そこで外部コマンドですよ（以下無限ループ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 07:03:14

行動あるのみ!!

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:05:21

>>544
> 3GHzマシンなのにnavi2chでスレを開くとき10秒前後待たされる。

XP,PenM1.7Gで3秒程度だから単に回線が重いとかメモリがないとかの
問題じゃないのか?

**544** · 2006/04/13(木) 08:12:30

メモリは1.5GB。回線速度の問題を避けるためoffline。
これだけのスペックがあるならそもそも1秒以上かかるのがおかしいんだよね。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:17:42

>>571
痛々しい箇所の具体例きぼん

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:20:30

>>544
設定すらまともにできないあほがｗ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:20:57

>>566
個人的な不満点。
auto-revert-modeとか設定しているとファイルを
開けば開くほど重くなる。
（auto-revert-intervalを増やすことで回避）

jit-lock-modeは巨大なファイルには重い。
fast-lockでキャッシュしたほうがはじめに開くのが遅いが
その後は速い。だがauto-revertと相性が悪い。

フォントの色変えぐらいはネイティブにならないかなぁ

**544** · 2006/04/13(木) 08:29:31

>>573
俺のemacs設定ファイルは1万行を超えますが？
>>572
w3m-fontifyなどわざわざ遅い言語で黙々とテキストをパースしているところ
おかげで待たされる待たされる

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:33:10

行数の多さはまともさと関係ないだろ。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:34:49

>>571
offlineということは一度開いているファイルを開くんだろ。
キャッシュバッファを消して試したが1秒もかからん。
おまいの環境が悪いだけだ。

**544** · 2006/04/13(木) 08:35:07

しょうがないから最新50記事のみ表示するようnavi2chを設定している。短気なんでな。

**544** · 2006/04/13(木) 08:39:15

そりゃあ短いスレなら1秒もかからんだろうが。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:48:46

>>578
そんな設定しなくても速いよ、普通は。
おまいの環境が悪いと言っているだろう。
もう一度見直せ。elispのせいにすんじゃねぇ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 08:49:30

こいつ頭悪すぎて話しにならねぇなｗ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 09:31:57

バイトコンパイルしてないってオチだったりして。
それからelispのパフォーマンスはEmacs自体のコンパイル時の最適化オプションで結構変わる。
きつめに最適化した方がEmacs自体のコンパイルには時間がかかるが、make bootstrap全体ではむしろ速かったりする。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 09:55:54

w3m-fontify が遅いって人が定期的に沸くんですが～
糞コテの人ですか?

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 09:57:51

>>575
w3m-fontifyをどう改良すればいいと思う？

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 10:01:17

>>582
ほうほう。体感できるほど影響あるすか?

蛇足だけど bootstrap (= byte compile) の処理時間と elisp の実行速度って
直結しないような気がするんだけどそうでもないのかね。

**キング** · 2006/04/13(木) 10:54:24

最速の emacs を組み立てた者には褒美をさしあげよう
もちろんウィンドウズ版な

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 11:59:30

>>585
春やなぁ。バイトコンパイルもやらずに遅い遅いと言っていたのか・・・

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 12:35:00

せっかく 2 回コンパイルするんだから profile を使った最適化をするよう、
こんな感じにすればかなり (手元では 10% 以上) elisp 周りが速くなる。

Index: Makefile.in
@@ -782,8 +782,8 @@
bootstrap-build: FRC
(cd lisp; $(MAKE) $(MFLAGS) bootstrap-prepare)
- (cd src; $(MAKE) $(MFLAGS) bootstrap)
+ (cd src; $(MAKE) $(MFLAGS) bootstrap CC='$(CC) -fprofile-generate' )
(cd lisp; $(MAKE) $(MFLAGS) bootstrap EMACS=../src/bootstrap-emacs${EXEEXT})
(cd src; $(MAKE) $(MFLAGS) mostlyclean)
- $(MAKE) $(MFLAGS) all
+ $(MAKE) $(MFLAGS) CC='$(CC) -fprofile-use' all
(cd lisp; $(MAKE) $(MFLAGS) bootstrap-after)

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 12:37:29

>>587
あ、すまん、585 != 544 ね。
影響ってのはコンパイルオプションのほうの話ね。

**582** · 2006/04/13(木) 15:01:00

さっき試したら-O2より-O3の方がmake bootstrap全体で時間がかかってた orz -Oなしよりは早く終わったけど。
CFLAGSで-I...や-D...を指定する際、下手をするとデフォルトの-O2を潰してしまうので注意が必要。

> bootstrap (= byte compile) の処理時間と elisp の実行速度って直結しないような気がするんだけど
バイトコンパイラもelispで書かれているので、基本的なデータ処理のベンチマークにはなる。
もちろん、本当に速くしたいものとバイトコンパイラとで処理の内容が違うということはあるかもしれないが。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 17:25:58

話題を変えよう。RMSのMって何かな？

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 17:31:02

>>591
http://ja.wikipedia.org/wiki/RMS

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 17:58:37

うお、サンクス。昔から疑問が解けますた。
Richard Matthew Stallmanだったのか。

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 19:57:18

所詮 EmacsLisp など glue language なのさ

**名無しさん＠お腹いっぱい。** · 2006/04/13(木) 19:58:16

あいたん・・・

**名無しさん＠お腹いっぱい。** · 2006/04/14(金) 00:31:49

日本語変換(input method)のjapaneseを使って
どうやってカタカナに変換したらよいですか？
japanese-katakanaを使うしかないですか？
wnn,skkなどの導入はできないものとします。