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/04(火) 10:45:49

俺はGNU真理教信者だ
RMS尊師に栄光あれ

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

GPL3には賛同できないけどな。

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

GPL3ってまだ考案中だっけ？
反発が強いとまた変わってくるんじゃないかと
どういう結論であれ俺は尊師についていきます

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

正規表現オブジェクトを導入してほしい。
(re "foo")で正規表現がコンパイルされた形式に変換される。

lexical-letもprimitiveにすればより速いbytecodeを吐ける気がする。
だれかやってくれないかな。

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

正規表現のコンパイル結果はキャッシュされてるのであまり効果なし
lexical-let は lexbind ブランチで作業中

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

>>428
なるほど。あと文字列・配列・リスト関数のprimitiveを強化してくれると相当速くなりそう。

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

だれか、リージョン比較(tool > compare > regions)の使い方詳しく教えてくれ・・・・

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

C-h k (あるいは M-x describe-key RET)した後、そのメニューの項目を選んでみ。

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

>>423
そんなにIRCをやってるわけじゃないんで比較出来ない。。。

あと、いざというときに役立つeshellのtips。

etagsはEmacsに標準でついてくるけどディレクトリを再帰的に
たどる機能がない。
普通はfindを使うんだろうけど、cygwinとか入れてないと使えない。
そんな時は、eshellを起動して以下を打ち込む。

$ ls -1 hoge/**/*.[ch] | etags -

で、eshellがhoge以下を再帰的にたどったリストを作ってetagsに渡してくれる。

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 01:58:20

外部コマンドくらい面倒がらずに入れろよ

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 02:10:23

外部コマンドを使ったら負けかなと思っている。

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 03:59:10

はぁ？寝言は寝て言え
餅は餅屋だろうが

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

Emacs星人にそんなこと言うな(ｼｭﾜｯﾁ!

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

しょせんEmacsとてUnixコマンドよ

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 11:43:24

言うの忘れたがわしもEmacs星人だ

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 17:52:43

すいません、うんこはちゃんとコテ名乗ってください。

**438** · 2006/04/05(水) 18:17:48

一人称は「わし」だが、わしは断じてウ○コではない

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 20:48:57

multi-tty を使えば X 上で動いてる emacs を tty からも
同時にいぢれるんですよね?

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 21:24:22

Emacs multi-tty support
http://lorentey.hu/project/emacs.html.hu

ただxemacsなら素のままで可能ですよ。

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 23:20:01

>>442
xemacs はあまり好きじゃないんだ。
とりあえず multi-tty コンパイルしてみるよ。

**名無しさん＠お腹いっぱい。** · 2006/04/05(水) 23:37:16

xemacsは亜流ですもんね

**名無しさん＠お腹いっぱい。** · 2006/04/06(木) 03:35:53

>>137-141

128 のパッチだけだと不十分な場合あり。（GNU ld の
バージョンによる。）

Solaris 8 のころにすでにぶつかって困った問題です。
Solaris sparcでも solaris x86 でも起きます。

普通にconfigure してから
Makefile の LDFLAGS に
LDFLAGS=-z nocombreloc -L/usr/openwin/lib
を加える。

なので、ひるがえってこんな感じで configure する。

solaris10 の例：
env LDFLAGS="-z nocombreloc" MAKE=gmake CC="$CC" ./configure --prefix=/opt/csw/ --with-xim=no

"-z nocombreloc" を使うには gnu ld でないとうまくないはず。

細かなところは３年くらいまえの GCC のメイリングリストみると
でてますが、エッセンスは 128 の話と、その当時多少 clever に
なりはじめた ld の問題ということ。

22 だと unexec が賢くなってるのかな。（そうならちょっと驚き。）
単に上の -z nocombreloc がdefault で入っているだけ？（これもそうなら
ちょっと驚き。）

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

python-mode を使用していますが、'''string ...''' と """string ..."""
をうまく font-lock してくれない場合があります。何かこの問題への対処法はありますか？

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

具体的なソースを示してくれ。
ちなみにc?perl-modeやruby-modeならfont-lockが混乱しているときに
「# "」などと行末にいれるのが常套手段となっている。
python-modeなら「# """」とかかな。

**名無しさん＠お腹いっぱい。** · 2006/04/06(木) 15:28:20

>>447
へー。はじめて知った。

**名無しさん＠お腹いっぱい。** · 2006/04/06(木) 16:00:28

Emacs使いの常識

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

Emacs使いのバッドノウハウ

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

エレガントじゃないよなぁ

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

しょせん正規表現で見ているんだからしょうがない。
文法が変態な言語ならよくある。
高精度のparserをサブプロセスで動かせば改善すると思う。

**名無しさん＠お腹いっぱい。** · 2006/04/06(木) 23:42:43

文字列の中に改行が入ってる? 晒してみたら。

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 03:57:02

レス遅くなってすみません。以下のような文字列の時、色がうまくつきません。

'''
Of the form:
d = { key1 : value1 ,
key2 : value2 ,
...,
key_n : value_n }
'''

"""
BBC News
Fears for Colombia Indian groups
Israeli missiles hit PA compound
Albania targets speedboat outlaws
"""

一行の時は大丈夫なんですけれどね。一応自分の .emacs にも font-lock-add-keywords の中に

("[rRU]?\$'''[[:blank:]]*[^\r\n][[:graph:][:blank:]\n\r]*?'''\\|\"\"\"[[:blank:]]*[^\r\n][[:graph:][:blank:]\n\r]*?\"\"\"\$" 0 font-lock-doc-face append)

を入れてます。 re-builder では上の表現でしっかり文字列をキャプチャーしてくれるのですが、
font-lock はなぜかしてくれないです。

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 04:59:16

そもそもfont-lockは複数行をサポートしていないはず

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

>>455
"完全には" サポートされてないって感じですね。既に font-lock-multiline が t になってるけど、
それでも駄目みたいなので。。。 emacs-wiki.el あたりを見れば対処方が載ってるかな？

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 06:07:32

「完全には」って何に付いて言っているの?

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 06:35:39

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

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 12:58:48

そろそろ制度の高いparserを導入して脱font-lockしないといけないと思う。
nxml-modeはfont-lockを使ってないからね。

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 14:20:05

>>457
「font-lock-multiline とかの変数があったり、一応
複数行もシンプルな正規表現の場合は色がきちんと付いたりと、サポートする
努力はみられるけど、やっぱり完全にはサポートされてないなー」の「完全には」です。

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

それ何度やっても付きます？自分は付く時と付かない時があります。

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 14:26:15

>>459
> そろそろ制度の高いparserを導入して脱font-lockしないといけないと思う。
> nxml-modeはfont-lockを使ってないからね。
その nxml-mode ってすごそう。全部で 17,000 行ぐらいとか言ってるし

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

言語と別に Emacs 側で parser 作るのもなんかむだっぽいな。
言語側にやらせたりできないかな。

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

うん、Rubyの場合はRipperというparserがあるけど、あれはインタプリタから抜き出したらしい。
RubyならRipperなparserをサブプロセスにすればよさげ。
他の言語だとどうなのか。

**名無しさん＠お腹いっぱい。** · 2006/04/07(金) 23:58:45

>>462
こんなところで唸っても何にもならないので
御大に直接メールしてください。

**名無しさん＠お腹いっぱい。** · 2006/04/08(土) 00:45:30

>>462をやりたくてもライセンスの問題とか大丈夫なんだろうかね

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

>>460
> それ何度やっても付きます？自分は付く時と付かない時があります。

おまえバカだろ。だったら付かない時を再現できるよう前後のコードを
示さにゃ誰もわからんだろうよ。

**名無しさん＠お腹いっぱい。** · 2006/04/08(土) 01:43:23

>>466
付く時と付かない時があるっつってんだから前後は関係ないのではなかろうか。
ま、>>460の説明が下手だってのはそうなんだけど、なんとなくそう思ったり。

**名無しさん＠お腹いっぱい。** · 2006/04/08(土) 02:03:06

>>465
ライブラリとしてリンクするんじゃなくて、パイプでつないで外部プロセスから結果だけ受け取るようにすればOK？

>>461
nxml-modeは確かにすごいねー。中で何やってるんだあれ？ソース追いかけてもなにか「すごそう」なことをしていることしかわからなかった。
ただ、1000,2000行くらいを超えるXMLファイルを編集しはじめると、非常に重くなる。もったいない・・・あれをCで再実装してくれんかね。

**名無しさん＠お腹いっぱい。** · 2006/04/08(土) 02:59:06

>>468
マシンスペックは？
やはり重くなるのか‥しょせんのろまのEmacsLispか
nxml-modeでつこてるparserをCで実装してパイプでつなぐと速くなるのかな？

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 01:47:51

>>468
その外部プログラムのライセンスは？
さらにEmacs添付にするにはFSFの書面が必要だが

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 01:56:18

添付しなくてもいいんでは。

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 01:58:36

日本語のテスト

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 02:19:25

ん、navi2chで初カキコ？

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 14:30:52

質問です。
自分はEshellを使用しているのですが、特定のコマンド(例えばmysqlとか)の
standard outputの内容がうまくEshellバッファに反映されません。
何か解決策はあるでしょうか？

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 16:04:32

イイシェルという名前ははったりだ。普通のshellを使えばいいこと。

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 21:48:42

だから、OpenType Emacs と、multi-tty Emacs と、Unicode Emacs と、Lexical Binding Emacs はいつ本家に入るんだ！！

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 22:24:35

multi-ttyは次入るんじゃなかったけ？
UnicodeはEmacs22/23じゃないけ？
はよLexical BindingとDynamic Libraryを本家に入れてくれ。
とくにfont-lockが遅すぎて困るんだ。

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 22:41:29

lexical にしたらマルチスレッドにしやすい？

**名無しさん＠お腹いっぱい。** · 2006/04/09(日) 22:43:44

later-do.elで疑似マルチスレッド
concurrencyならIPCでも十分な希ガス
lexicalにすると高速化されるとは思う

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

>>477
あとportable dumper Emacs もこのリストに入れてくれや。

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 03:17:44

はっきし言って起動時間などどーでもいい
なぜならEmacsの起動時間==uptimeだからだ

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 03:23:43

Emacsの最大の欠点…それはEmacsLispがあまりにも遅すぎることだ。
それさえなんとかしてくれれば神環境なんだが。

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 07:12:34

俺にとっては emacs はもう既に神領域に逹っしてるよ

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 08:58:07

>>482
何をしているときに遅いの？
下手な設定しているんじゃないの?

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

>>484

482 じゃないけど、 xdisp.c の末尾から C-M-a してみるとか。

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 12:54:03

そういえば elisp の最適化についてはバイトコンパイル以外では訊きませね。

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

>>484
数万行のソースファイルのfont-lock
emacs-w3mのfonfity
プロセスの入出力
primitive不足のため雑多な文字列処理も遅い

**名無しさん＠お腹いっぱい。** · 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 で書く部分をずいぶん減らせるはず。

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 16:27:17

>>488
common lispと比べられてもなぁ…。

vimの関数とか、秀丸マクロと比べてみるとか(笑)

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 17:24:36

taraiなんて関数呼び出しの速さ以外は判らないし。

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 18:44:17

>>488 ついでにRuby、Luaも入れてちょ

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

>>488
Emacs 21.4での結果もたのむ

**名無しさん＠お腹いっぱい。** · 2006/04/10(月) 23:26:14

質問スマソ。
PCL-CVSで、

cvs update -rhoge

みたいに、タグ指定でcvs updateするにはどのコマンドを使えばいいのでしょうか？

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

グダグダ文句たれる前にお前等が elisp の最適化に取り組んでみたらどうだ？

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

だが断る!

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

やったところでそう簡単に取り込んでもらえるとは思えないね
書面が必要な上rmsを説得せねばならん

**名無しさん＠お腹いっぱい。** · 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でいっぱつ。