トップページ⇒unix
1001コメント261KB

Emacs part 18

■ このスレッドは過去ログ倉庫に格納されています
0001フンバリャーウンコ・ヨーデル ◆xlAOIq6jZw 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/
0458名無しさん＠お腹いっぱい。2006/04/07(金) 06:35:39
>>454
軽く試したけどちゃんと色ついてるけどなあ。

0459名無しさん＠お腹いっぱい。2006/04/07(金) 12:58:48
そろそろ制度の高いparserを導入して脱font-lockしないといけないと思う。
nxml-modeはfont-lockを使ってないからね。
0460名無しさん＠お腹いっぱい。2006/04/07(金) 14:20:05
>>457
「font-lock-multiline とかの変数があったり、一応
複数行もシンプルな正規表現の場合は色がきちんと付いたりと、サポートする
努力はみられるけど、やっぱり完全にはサポートされてないなー」の「完全には」です。

>>458
> >>454
> 軽く試したけどちゃんと色ついてるけどなあ。

それ何度やっても付きます？ 自分は付く時と付かない時があります。
0461名無しさん＠お腹いっぱい。2006/04/07(金) 14:26:15
>>459
> そろそろ制度の高いparserを導入して脱font-lockしないといけないと思う。
> nxml-modeはfont-lockを使ってないからね。
その nxml-mode ってすごそう。全部で 17,000 行ぐらいとか言ってるし
0462名無しさん＠お腹いっぱい。2006/04/07(金) 14:35:07
言語と別に Emacs 側で parser 作るのもなんかむだっぽいな。
言語側にやらせたりできないかな。
0463名無しさん＠お腹いっぱい。2006/04/07(金) 14:52:00
うん、Rubyの場合はRipperというparserがあるけど、あれはインタプリタから抜き出したらしい。
RubyならRipperなparserをサブプロセスにすればよさげ。
他の言語だとどうなのか。
0464名無しさん＠お腹いっぱい。2006/04/07(金) 23:58:45
>>462
こんなところで唸っても何にもならないので
御大に直接メールしてください。
0465名無しさん＠お腹いっぱい。2006/04/08(土) 00:45:30
>>462をやりたくてもライセンスの問題とか大丈夫なんだろうかね
0466名無しさん＠お腹いっぱい。2006/04/08(土) 01:08:29
>>460
> それ何度やっても付きます？ 自分は付く時と付かない時があります。

おまえバカだろ。だったら付かない時を再現できるよう前後のコードを
示さにゃ誰もわからんだろうよ。
0467名無しさん＠お腹いっぱい。2006/04/08(土) 01:43:23
>>466
付く時と付かない時があるっつってんだから前後は関係ないのではなかろうか。
ま、>>460の説明が下手だってのはそうなんだけど、なんとなくそう思ったり。
0468名無しさん＠お腹いっぱい。2006/04/08(土) 02:03:06
>>465
ライブラリとしてリンクするんじゃなくて、パイプでつないで外部プロセスから結果だけ受け取るようにすればOK？

>>461
nxml-modeは確かにすごいねー。中で何やってるんだあれ？ソース追いかけてもなにか「すごそう」なことをしていることしかわからなかった。
ただ、1000,2000行くらいを超えるXMLファイルを編集しはじめると、非常に重くなる。もったいない・・・あれをCで再実装してくれんかね。
0469名無しさん＠お腹いっぱい。2006/04/08(土) 02:59:06
>>468
マシンスペックは？
やはり重くなるのか‥しょせんのろまのEmacsLispか
nxml-modeでつこてるparserをCで実装してパイプでつなぐと速くなるのかな？
0470名無しさん＠お腹いっぱい。2006/04/09(日) 01:47:51
>>468
その外部プログラムのライセンスは？
さらにEmacs添付にするにはFSFの書面が必要だが
0471名無しさん＠お腹いっぱい。2006/04/09(日) 01:56:18
添付しなくてもいいんでは。
0472名無しさん＠お腹いっぱい。2006/04/09(日) 01:58:36
日本語のテスト
0473名無しさん＠お腹いっぱい。2006/04/09(日) 02:19:25
ん、navi2chで初カキコ？
0474名無しさん＠お腹いっぱい。2006/04/09(日) 14:30:52
質問です。
自分はEshellを使用しているのですが、特定のコマンド(例えばmysqlとか)の
standard outputの内容がうまくEshellバッファに反映されません。
何か解決策はあるでしょうか？
0475名無しさん＠お腹いっぱい。2006/04/09(日) 16:04:32
イイシェルという名前ははったりだ。普通のshellを使えばいいこと。
0476名無しさん＠お腹いっぱい。2006/04/09(日) 21:48:42
だから、OpenType Emacs と、multi-tty Emacs と、Unicode Emacs と、Lexical Binding Emacs はいつ本家に入るんだ！！
0477名無しさん＠お腹いっぱい。2006/04/09(日) 22:24:35
multi-ttyは次入るんじゃなかったけ？
UnicodeはEmacs22/23じゃないけ？
はよLexical BindingとDynamic Libraryを本家に入れてくれ。
とくにfont-lockが遅すぎて困るんだ。
0478名無しさん＠お腹いっぱい。2006/04/09(日) 22:41:29
lexical にしたらマルチスレッドにしやすい？
0479名無しさん＠お腹いっぱい。2006/04/09(日) 22:43:44
later-do.elで疑似マルチスレッド
concurrencyならIPCでも十分な希ガス
lexicalにすると高速化されるとは思う
0480名無しさん＠お腹いっぱい。2006/04/09(日) 22:58:09
>>477
あとportable dumper Emacs もこのリストに入れてくれや。
0481名無しさん＠お腹いっぱい。2006/04/10(月) 03:17:44
はっきし言って起動時間などどーでもいい
なぜならEmacsの起動時間==uptimeだからだ
0482名無しさん＠お腹いっぱい。2006/04/10(月) 03:23:43
Emacsの最大の欠点…それはEmacsLispがあまりにも遅すぎることだ。
それさえなんとかしてくれれば神環境なんだが。
0483名無しさん＠お腹いっぱい。2006/04/10(月) 07:12:34
俺にとっては emacs はもう既に神領域に逹っしてるよ
0484名無しさん＠お腹いっぱい。2006/04/10(月) 08:58:07
>>482
何をしているときに遅いの？
下手な設定しているんじゃないの?
0485名無しさん＠お腹いっぱい。2006/04/10(月) 10:49:26
>>484

482 じゃないけど、 xdisp.c の末尾から C-M-a してみるとか。
0486名無しさん＠お腹いっぱい。2006/04/10(月) 12:54:03
そういえば elisp の最適化についてはバイトコンパイル以外では訊きませね。
0487名無しさん＠お腹いっぱい。2006/04/10(月) 14:17:18
>>484
数万行のソースファイルのfont-lock
emacs-w3mのfonfity
プロセスの入出力
primitive不足のため雑多な文字列処理も遅い
0488名無しさん＠お腹いっぱい。2006/04/10(月) 14:52:18
パフォーマンスを語る時は計測しなきゃ。
(tarai 12 6 0) の結果:
Emacs 22.0.50: 5.125
CLISP 2.38: 2.499
SBCL 0.9.11: 0.396
GCC 3.4.4: 0.14
バイトコードコンパイラの CLISP と比べても Emacs Lisp は 2 倍以上遅い。
SBCL くらい速ければ C で書く部分をずいぶん減らせるはず。
0489名無しさん＠お腹いっぱい。2006/04/10(月) 16:27:17
>>488
common lispと比べられてもなぁ…。

vimの関数とか、秀丸マクロと比べてみるとか(笑)
0490名無しさん＠お腹いっぱい。2006/04/10(月) 17:24:36
taraiなんて関数呼び出しの速さ以外は判らないし。
0491名無しさん＠お腹いっぱい。2006/04/10(月) 18:44:17
>>488 ついでにRuby、Luaも入れてちょ
0492名無しさん＠お腹いっぱい。2006/04/10(月) 23:12:19
>>488
Emacs 21.4での結果もたのむ
0493名無しさん＠お腹いっぱい。2006/04/10(月) 23:26:14
質問スマソ。
PCL-CVSで、

cvs update -rhoge

みたいに、タグ指定でcvs updateするにはどのコマンドを使えばいいのでしょうか？
0494名無しさん＠お腹いっぱい。2006/04/11(火) 00:53:36
グダグダ文句たれる前にお前等が elisp の最適化に取り組んでみたらどうだ？
0495名無しさん＠お腹いっぱい。2006/04/11(火) 00:56:22
だが断る!
0496名無しさん＠お腹いっぱい。2006/04/11(火) 00:56:23
やったところでそう簡単に取り込んでもらえるとは思えないね
書面が必要な上rmsを説得せねばならん
0497名無しさん＠お腹いっぱい。2006/04/11(火) 01:02:21
>>496
fork しようよ。
0498名無しさん＠お腹いっぱい。2006/04/11(火) 01:07:55
スクリプト言語を使って高速な数値計算するときはスクリプトでループを回してはいけないのが常識だが、
Emacsにもそれを適用してみるのはどうだろう？
探索や置換をprimitiveにするとそこそこ高速になると思う。
0499名無しさん＠お腹いっぱい。2006/04/11(火) 01:09:23
forkしたらしたで本家との非互換性が出てきて動かないEmacsLispが出てきたりとかするのが困る。
xemacsなんてたとえてみればアミバ流北斗神拳だろ。
0500名無しさん＠お腹いっぱい。2006/04/11(火) 01:11:49
バッファにたいしてGNU grepのアリゴリズム使えないのかな…
0501名無しさん＠お腹いっぱい。2006/04/11(火) 01:14:20
>>500
> アリゴリズム
05025002006/04/11(火) 01:15:19
しまった、typoしてしもうたorz
0503名無しさん＠お腹いっぱい。2006/04/11(火) 10:45:30
>>496
日本人の最大の欠点。
英語で議論できない。

パッチだけ送って取り込まれないとごねる。
0504名無しさん＠お腹いっぱい。2006/04/11(火) 13:10:30
英語を母国語にしていてもあのrmsを説得するのは至難の業だと思うが
0505名無しさん＠お腹いっぱい。2006/04/11(火) 13:55:17
日本人だからと決め付けるのはとんだ偏見ですね
0506名無しさん＠お腹いっぱい。2006/04/11(火) 14:18:10
mule入ったやん
rmsは始めごねてたのに
0507名無しさん＠お腹いっぱい。2006/04/11(火) 14:55:35
最初ごねるのはしょうがない。彼等にとって他言語などどーでもいいのだから。
0508名無しさん＠お腹いっぱい。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.

ということで終了だもん。途中で言ってること変えるんだから議論のしようがない。
0509名無しさん＠お腹いっぱい。2006/04/11(火) 18:29:25
だめぽ
0510名無しさん＠お腹いっぱい。2006/04/11(火) 18:48:11
別に変わってないだろ、2倍より速くなったら入れると確約したわけじゃあるまいし。
俺自身も遅いマシンでベイジアンフィルタつきnavi2chで見るために
バイトコードをx86のネイティブコードに変換するのを自分で実装して
一時期使ってたりしたけどさ。
それ自体は仕事としては、あまり前向きな仕事じゃないんだよ。
どうせ真面目に高速化を考えてもっていこうとすると今のelispをそのまま扱う
んじゃなくなるだろうから、かなりのreworkというかやり直しになるんだし。

メールを見るに、そのパッチを投げた人もそのへんわかってるんじゃないかと思うけど。
自分では何もしない人から見ると面白そうだけど、
やってみればその仕事の価値というか位置付けみたいなものは自分でわかる。
0511名無しさん＠お腹いっぱい。2006/04/11(火) 19:05:00
結局Emacsアプリはもっと外部コマンド指向にしろってこったな。
rmsはEmacsLispを高速化する気さらさらないんだから。
navi2chもpure elispだなんて愚かな設計だよ。
誰かEmacsで動く高速な2chブラウザ開発してないかね。
0512名無しさん＠お腹いっぱい。2006/04/11(火) 19:07:22
その点Mewはいい設計だと思う。
EmacsLispが遅いことを知っているからこそ時間のかかる処理を外部コマンドにやらせている。
0513名無しさん＠お腹いっぱい。2006/04/11(火) 19:10:26
一般的に、開発が進むと、外部コマンドで行なっていた処理を
どんどん内部化するという傾向があるように思うのだけど、
あれはどういう理由なの?

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

何か問題があるの?
0514名無しさん＠お腹いっぱい。2006/04/11(火) 19:13:29
具体例をもってきた方が話しやすいと思う。
0515名無しさん＠お腹いっぱい。2006/04/11(火) 19:13:34
>>513に激しく同意だ。
ユーザに外部コマンドをインストールさせるのが面倒だとか考えてんじゃないの？
ユーザとしては動作が遅くなる方が大問題なんだけど。
emacs-w3mもnavi2chもソース見てて痛々しいんだよな。
0516名無しさん＠お腹いっぱい。2006/04/11(火) 19:17:04
結局のところ、EmacsLispは計算処理をするのが苦手で直す気ないんだから、
計算処理は外部コマンド、入出力、表示のみEmacsLispというのが最適解なんだろうね。
0517名無しさん＠お腹いっぱい。2006/04/11(火) 19:48:09
>>512
mewは確かに、
mewencode, mewl, incm, mewstunnelを持っているけど、
昔に比べると徐々にelispを使う方向になってきている。
0518名無しさん＠お腹いっぱい。2006/04/11(火) 20:10:40
まじかよorz
なんか1.xx時代はとても速かったのに。
0519名無しさん＠お腹いっぱい。2006/04/11(火) 20:21:24
>>517
IMがmewのバックエンドだった。
05205172006/04/11(火) 20:26:35
昔は、
$ imls +フォルダ名 > ~/Mail/フォルダ名/.mew-cache
ってやってた。万単位のメールあるところで。

今は全部elispで書けるから、設定の自由度上がったけれど、遅いね。
0521名無しさん＠お腹いっぱい。2006/04/11(火) 20:31:21
わざわざEmacsLisp化して遅くするなんて正気の沙汰とは思えんね。
0522名無しさん＠お腹いっぱい。2006/04/11(火) 20:52:56
いろんなプラットフォームで動く外部コマンド書くのもつらくない？
0523名無しさん＠お腹いっぱい。2006/04/11(火) 20:54:02
>>522
> いろんなプラットフォームで動く外部コマンド書くのもつらくない？

Perl/Rubyでいっぱつ。
0524名無しさん＠お腹いっぱい。2006/04/11(火) 20:55:57
そういや、設定/カスタマイズ関係が厄介という問題があったねえ。
まあ、なんらかの標準化や翻訳メカニズムを作ってしまえば、それで
行けるのだろうけど。
0525名無しさん＠お腹いっぱい。2006/04/11(火) 21:35:15
>>523
べつにCでもいいじゃん。小規模のものなら誰かが移植してくれる。
>>524
それはひとえに設計が悪いからじゃないのか？
EmacsLispでオプションを設定してコマンドラインで渡せばいいだろ。
0526名無しさん＠お腹いっぱい。2006/04/11(火) 23:36:33
ELisp で書いてあると、各種 hook とか advice とかでいじりやすい。
昨今の強力なマシンなら Emacs だけで処理してもなんとかなるし。
速さより手軽にいじれることのが重要になってくんでしょ、きっと。
0527名無しさん＠お腹いっぱい。2006/04/11(火) 23:53:21
>>512
MewはMH-Eの代替品だからああいう形になっているのかと思っていた。
そういえば、最近のMewのInfoからはMH-Eの悪口消えたのね。
0528名無しさん＠お腹いっぱい。2006/04/12(水) 00:42:42
>>515
emacs-w3mはw3の二の舞になってるね。

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

>>527
なつかしい、俺がLinux駆け出しだったころ悪口書いてあったな。
0529名無しさん＠お腹いっぱい。2006/04/12(水) 00:47:19
>>526
Pen4の3GHzだけど遅く感じることがあるんだけど。
0530名無しさん＠お腹いっぱい。2006/04/12(水) 00:48:24
そもそもemacsをCに「移植」しようという試みは過去に何度あったのでしょうか？
0531名無しさん＠お腹いっぱい。2006/04/12(水) 00:49:50
はぁ？もともとCで書かれてるだろうが。
0532名無しさん＠お腹いっぱい。2006/04/12(水) 01:30:08
lisp 部分が遅いのはダイナミックスコープと関係ある？
0533名無しさん＠お腹いっぱい。2006/04/12(水) 01:36:57
vimはほとんどCで実装されていて高機能な割に高速なエディターだけど、
ソースはとんでもなく読み辛くて汚い。

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

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

外部コマンドなんかにしたら、なおさらブラックボックス化してくよ。
0534名無しさん＠お腹いっぱい。2006/04/12(水) 01:42:38
いろんなプラットホームで使ってると、
外部コマンドに依存するのはいやだなぁ。
0535名無しさん＠お腹いっぱい。2006/04/12(水) 01:44:03
なぜ？
0536名無しさん＠お腹いっぱい。2006/04/12(水) 01:52:57
EmacsLispは遅いんだから結局外部コマンドに頼るしかないのが現状なんだよ。
rmsは高速化する気まったくないようだから。
インストールが面倒とか言う厨房はかえれ。
0537名無しさん＠お腹いっぱい。2006/04/12(水) 01:55:47
まあまあ、議論して結論を出そうとしてもしょうがないのだから。
「主張して実践する」ことで示すしかないのだし。

ここはそれぞれの方法の利点欠点をリストアップして、
インプリメントの一助にするのが建設的。
0538名無しさん＠お腹いっぱい。2006/04/12(水) 02:08:50
>>487
も言ってるけど、primitive不足ってのが最大の理由だろう。
0539名無しさん＠お腹いっぱい。2006/04/12(水) 02:25:50
しかし、開発陣はそれを認めようとしないんだよね
かといってdynamic linkも本家に取り込んでくれない
だから高速化したければ外部プロセスに追い出すのが現実的
0540名無しさん＠お腹いっぱい。2006/04/12(水) 02:30:40
Rubyは実行速度の遅さを拡張ライブラリでカバーしているからこそ成功している。
Emacsもそうしてもらいたいものだね。
0541名無しさん＠お腹いっぱい。2006/04/12(水) 07:15:40
確かに e-lisp が遅いと感じる人もいるだろうし、
外部プロセスに渡して幸せになりたいのも判るけど、
自分は現状で満足な訳で。

まぁつまり、ぐだぐだ言うより外部プロセスをかっこよく使って
高速に動くソフトをいっぱい書いて布教した方が建設的じゃね?
0542名無しさん＠お腹いっぱい。2006/04/12(水) 08:12:26
>>541
> 高速に動くソフトをいっぱい書いて布教した方が建設的じゃね?

そうしましょう、そうしましょう。
0543名無しさん＠お腹いっぱい。2006/04/12(水) 08:46:25
>>515
痛々しい箇所の具体例きぼん
0544名無しさん＠お腹いっぱい。2006/04/12(水) 15:51:16
>>543
多すぎて書ききれない。
テキスト処理を黙々とやらせてるところ。
EmacsLispはテキスト処理苦手なんだってば。

3GHzマシンなのにnavi2chでスレを開くとき10秒前後待たされる。
emacswikiのindexを開くのに何十秒も待たされる。
0545名無しさん＠お腹いっぱい。2006/04/12(水) 15:53:42
全部挙げろとは誰も言ってないから多すぎても別に困らんでしょ。
多すぎるならためしに2つ3つ挙げてみてよ。
0546名無しさん＠お腹いっぱい。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
0547名無しさん＠お腹いっぱい。2006/04/12(水) 19:23:38
set-default-coding-systems
0548名無しさん＠お腹いっぱい。2006/04/12(水) 19:25:33
set-process-coding-system
0549名無しさん＠お腹いっぱい。2006/04/12(水) 19:41:31
C-x RET c
0550名無しさん＠お腹いっぱい。2006/04/12(水) 20:52:55
>>545
馬鹿を追い詰めなさんな。
05515462006/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という環境では無理なのかとも思っています。
0552名無しさん＠お腹いっぱい。2006/04/12(水) 21:54:42
GNU Emacs 21.4ならあるけど
0553名無しさん＠お腹いっぱい。2006/04/12(水) 21:55:15
意見を述べた人を馬鹿呼ばわりとは、しょせん2chか
05545462006/04/12(水) 22:02:24
>>552
Meadow固有ですかね。こんな作りのネットインストール版です。
GNU Emacs 21.4.1 (i386-mingw-nt5.1.2600) of 2005-08-28 on CUBE
0555名無しさん＠お腹いっぱい。2006/04/12(水) 22:09:00
lispの下探ってみろよ。
0556名無しさん＠お腹いっぱい。2006/04/12(水) 22:56:52
M-x apropos set.+coding-system
してみろ
0557名無しさん＠お腹いっぱい。2006/04/13(木) 01:24:07
>>546
俺なら、
shell-command-on-region で、リダイレクトしちゃって、
delete-region
insert-file
で逃げる。
■ このスレッドは過去ログ倉庫に格納されています