> ちなみに、23.0.60.1と23.0.60.2でも変わってると思う
(ﾟДﾟ)ﾊｧ?

>>451
AAかけた日本語太字が出るようになったんだけど

何かダメな人っぽいのでどうでもいいけど

あ、日本語じゃないや、アルファベットだ

>>447
ありがとうございます。org-mode以外にもたまごとfont-lockは相性が悪いみたいです。

>>454
別にfontlockと相性が悪い訳じゃなくて、
intangibleなproperty使ってるmajor-modeと相性悪いだけだろ。
tamagoのフェンスがintangible使ってるからバッティングしてるだけ。

>>448のにアップデートしたらWanderlustで日本語フォルダが扱えなくなった。
内部文字コードが変った？
emacs22だと、
(utf7-encode "送信済みメール" t)
"&kAFP4W4IMH8w4TD8MOs-"

emacs23だと
(utf7-encode "送信済みメール" t)
"&,v+QAU,hbggwfzDhMPww6w-"

になってしまう。う～ん困った。

Wanderlust に附属の utf7.el(c) を消してしまって、Emacs に附属のを使えばどう?

>>448
俺はUbuntu Gutsy で

GNU Emacs 23.0.60.1 (x86_64-pc-linux-gnu, GTK+ Version 2.12.0)
of 2007-12-30 on osmium

使ってるけど、 emacs-snapshot のアップグレードパッケージがあがってたのは
知ってたけど、まずは様子で、実行しなかった。
これは正解だったってことだね 。。 よかった

>>457
正しくencodeされるようになったけど、Wanderlustではあいかわらずダメ。
>>458
パッケージどこかにないっすかね。ダウングレードしたい。。。

おい、おまいら！
ちょっと教えてください。

エディタを探してるんですが、vimを１週間ほど使ってみて結構気に入ってます。
が、Escキーを酷使するのと、モード切替時のIMEの勝手な振る舞いが
少し気になって、emacsも試してみたくなっています。

が、meadowやらgnuやらxやらで何を入れていいのかさっぱり分かりません。
windows日本語UTF-8でオススメのパッケージはどれでしょうか？

format c:
install ubuntu && apt-get install emacs-gtk

>>459
ここ、ここ
http://ppa.launchpad.net/avassalotti/ubuntu/pool/main/e/emacs-snapshot/

vim気に入ってるならvim使えばいいじゃん
馬鹿なの？

>>462
ありがとう。でもなかったorz

>>464
その環境で使える .deb パッケージなかったの？
それなら emacs-snapshot_20071229.orig.tar.gz をコンパイルしてインスコすればいいんじゃない？
ちなみにこれ、アンチエイリアスがかかってて綺麗なフォントが表示できる。

>>465
いや自分でビルドするの大変なので・・・
gustyの20071230版debパッケージはなかったよ。

つか、続きは該当のディストリスレでやれよ

>>463
頭大丈夫？？？
↓
が、Escキーを酷使するのと、モード切替時のIMEの勝手な振る舞いが
少し気になって、emacsも試してみたくなっています。

いちいちサーバにemacsをインストールしなくても、
サーバ上で簡単なプログラム(サーバプロセス)を起動するだけで、
手元のemacsからサーバ上のファイルをリモート編集できたら便利だと思うんだけど、
そういうパッケージってないのかなあ。

今でもtrampでssh経由のリモート編集が出来てるけど、とても遅いし、
ファイル補完ができたりできなかったりで安定しないし、
使いづらいというのが本音。シェル経由ってところに無理があると思った。

その機能が昔しょうもないセキュリティホールになって云々

sshが遅いならほかのも普通に遅いんじゃね？

>>469
ローカルは Windows? UNIX系同士ならそんなに遅くなかったと記憶してる。
Windows 上でも最近は結構速くなってきてる。個人的には常用可能。
cvs版だけど。

rshの速さは異常

>>469
何が言いたいのかわからんけど、nfs/sambaを使えばいいんじゃないの?
emacsがどうとか言う前にOSの使い方くらい覚えろよ。

trampはrsyncも使えるみたいだから試してみたら?

>>470
セキュリティは確保しなければいけないが、cookie等使えばやりようはあると思う。

>>471
trampはremoteの情報をとるのに、shellとかuudecodeとか駆使して、
時にはperl scriptまで送りつけたりしてadhocにやってるようだ。
リモート側のサーバプロセスと専用のプロトコルを使って、
必要な情報が一回のTCP sessionで取れれば、もっと速くかつ安定すると思ったわけ。
リモート側がshellの動作するUNIXでなければいけないという制約もなくせるし。

>>472
ローカル:Windows、リモート:UNIX
環境を選択できないので、NTEmacsを使わざるを得ない状況。

>>474
他人・他社が管理しているサーバにnfs/sambaをインストールさせるのは、
決して容易なプロセスではないよ。ていうか、たかがリモート編集のために
セキュリティポリシーまで変更させたくはない。

>>475
試していないが、Windows上では使えなさそうに見える。

他所様のサーバ上で得体の知れないプロセスを走らせるのは良くて
nfsやsambaは駄目という訳ですね

ユーザ権限で動く一般プロセスと
システムにインストールされるデーモンとでは
動かすにあたっての管理者の心構えが大違いなのは、当たり前じゃないかな?

メジャーなデーモン類と
得体の知れないプロセスを走らせるにあたっての
管理者の心構えの違いは?

しかしサーバは外なのかしら中なのかしら?

ユーザモードでnfsなりsambaなりiscsiなり好きなプロトコル喋るサーバを立てれば良いだけじゃね?
なんで即デーモンの話になるのかわからんけど。
でもたかがリモートでファイル編集するだけなのにお客様のサーバに得体のしれないぷろせすw(ry

つーかめんどくさがらずにローカルで編集して
scpなりrsyncなりすれ。

まぁ TRAMP も遅いっちゃ遅いけどねぇ。

でも CVS HEAD でメソッドを scp にしとけば、
我慢できないってほど遅くはないけどなぁ。
フレッツ 100M 経由で。

NTEmacs は使ったことないから知らないけど。

つかさ、サーバにヘンなデーモン入れるくらいなら
サーバの home にでも Emacs 入れといた方がマシじゃね?

俺もそう思う。
ただ、俺は管理が面倒だからしないが。

476によるkittyなセキュリティポリシーの解説を待ちわびるスレになりました。

まぁ、それでもnfs、sambaは危ないと思うよ

ていうか、そんな大物、走らせてくれないだろ

私はtrampでscpつかうっての我慢。
xterm (rxvt)の上ででemacs使う（ためにいろいろmakeしたり
設定したり日本語辞書ごのごのする）よりはまし。

>>481
それも一つの手なのだが、編集中のファイル群のコピーを持ち手で同期させるという戦略は
面倒だったり二重編集の危険性をはらんでいたりするから、もし避けられるならば避けたいものだ。

>>482
たしかに我慢できないほどの遅さではないからいま実際に使っているのだが、もしもっと速くできるのならば速くしたいものだ。

>>483
デーモンではなくて、ローカルのemacsからssh経由でリモート起動するコマンド。
現状の実装のtrampも、shellでは得られないfile attributeを得るのに
perl scriptをダイナミックに送り込んで実行している。
そのアプローチで、もっと一般化・longrun process化したものというイメージ。

リモート側にEmacsを置くと、ローカルがWindowsの場合別途X serverが必要になるし、
ホストごとにEmacsのインスタンスが別になってしまうだろう。
もし避けられるならば以下略

trampが可能にするリモート編集はおおいにEmacsを便利にしている。
ただしshellをベースにしたその実装方針には実行効率と安定性と移植性で疑問があるので、
同じ事をする別のもっと良い実装が既に存在したらいいなあ……と思って質問した。
http://www.emacswiki.org/cgi-bin/wiki/CategoryRemoteEmacs を見たが、
まだ存在しないようだ。

>>488
がんばって!!

>>488
なんで X が必要なの？ Putty とかでいいじゃんｗ

(let ((s (current-time))
e)
(find-file "/HOSTNAME:")
(setq e (current-time))
(message "%f" (- (+ (* (nth 0 e) 65536) (nth 1 e) (/ (nth 2 e) 10000000.0))
(+ (* (nth 0 s) 65536) (nth 1 s) (/ (nth 2 s) 10000000.0)))))

>>488 Linux/CVS HEAD だと、初回の find-file が 1-2 sec. くらい。

ただ、古い TRAMP はもっと遅かった覚えがあるよ。
ひょっとしたら TRAMP/Emacs を新しくすれば解決するかも?

使うとランダムでルート以下のファイルをひらく
フィーリングラッキーモードつくったんだけど誰かいる？

使い道は？

ファイルとの新しい出会い

リモートホストにg?ccとかがあったらCソースを送り込んでだな、、

1日何回転送するのかしらんが

ファイル編集の時間>>>tramp転送の時間じゃね？

きっとその熱意をもっと違うところにつぎ込んだ方がいい。
もっとも効果の得られるところに有限のリソースは費やすべき。

>>488 のようなひとは、
おそらく実際の転送速度とかより
みかけの操作速度が問題なんじゃないかな。わたしはわかる。
trampとかでfind-fileしたりセーブしたりするときに一操作でちょっと待たされる時間が
不快なんだよね。
コマンドラインからrsyncとか打ちこんでディレクトリごと手元にもってきて編集して
また戻す、とかってのが、
実際には時間かかってても気にならない、なんてこともある。

まあとにかく開発がんばってくれ。

一人じゃとてもと云うのなら、まずほしい仕様のドラフトでも
書いてみたらどうだ。

で、結局どこらへんがemacsと関係あるの?

trampとそのalternativeがemacsと関係ないと申すか?