dbus.elでnotifydを直接叩くという手ももも

>>794
うーむ。Org-mode って ascii な人が作っているのかな？
今、動かす環境がないので、コードをさらっと眺めただけで動作完全未保障だけれど、
次の patch をあてるとどうだろう？
;;; 要は、暗号化するときにあらかじめ utf-8 にエンコードしておくだけ。
;;; decrypt 側は utf-8 で decode-coding-string() してるんだけどね。

------8<------8<------8<------8<------8<------8<------8<------8<------
*** org-crypt.el.orig Fri May 14 03:10:48 2010
--- org-crypt.el Sat Jun 5 00:11:05 2010
***************
*** 121,127 ****
encrypted-text
(epg-encrypt-string
epg-context
! (buffer-substring-no-properties beg end)
(epg-list-keys epg-context crypt-key)))
(delete-region beg end)
(insert encrypted-text)
--- 121,129 ----
encrypted-text
(epg-encrypt-string
epg-context
! (encode-coding-string
! (buffer-substring-no-properties beg end)
! 'utf-8)
(epg-list-keys epg-context crypt-key)))
(delete-region beg end)
(insert encrypted-text)
------8<------8<------8<------8<------8<------8<------8<------8<------

おっと忘れた。
参照した org-mode のバージョンは org-6.36c.tar.gz ってやつだよ。

>>802
ありがとうございます。期待通りに 暗号->復号されました。

しかし Org-Mode は、UTF-8 以外は 推奨していないのだろうか？ もし、
どの文字コードでも可能なら

(encode-coding-string
(buffer-substring-no-properties beg end)
buffer-file-coding-system)

(org-decrypt-entry も同様に) が筋なのかな

>>799
自分のコンピューターのスペックです。

model name : Pentium III (Katmai)
cpu MHz : 551.310
cache size : 512 KB
MemTotal: 384600 kB

Emacs のコンパイルには 2時間位掛かったような、、、 まあコンパイルは
空いた時間にやればいいので

>>804
buffer-file-coding-system はファイルの内容によって変わる可能性があるから、
やめた方がよいよ。

たとえば euc-jp-unix なファイルに表現できない文字を加えると、
buffer-file-coding-system が変わってしまい、
euc-jp-unix な時に暗号化したものを復号すると化けてしまう。

とりあえず、一定で大きな coding-system を使っていれば実用上は問題ないと思う。
(utf-8 が適切か？という問題はあるかもしれないけれど、世の中の流れ的には
まあ妥当かと)

ファイル単体として見たときに、平文のところは euc-jp、 暗号化されたところの中身は
utf-8 になっているという気持ち悪さはあるかもしれないけどね。

core2 duo 2.16GHz で、-j 2 すると10分ぐらいかな。

make bootstrapだと結構時間かかるけど
src/以下だけなら1分以内で終わるな@core i3

ここにも格差が…

格差があるのに格和や格積がないのは不自然。

> src/以下だけなら

フルビルドの話なのに、なに言ってんだか。
lisp/はsrc/の10倍かかるわ。

Athlon64 X2 3800+ (2GHz) で make -j3 bootstrap が 11 分かからないくらい。

そもそも、LLなのにコンパイルという発想がきにいらない。
LLならばWrite Once, No Compile, Instant Runに徹せよ。

bootstrapで一番時間かかってるバイトコンパイルのところって並列になるの？

やれば分かるだろって話なんですが
EmacsはWindowsでしか使っていないので
UNIXの場合どうなのかなという疑問です

$ </proc/cpuinfo|grep 'model name'|sort -u
model name : Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz
$ time (make distcrean && ./configure && make -j5 bootstrap)
..
(; make distclean && ./configure && make -j5 bootstrap; ) 579.53s user 48.95s system 296% cpu 3:31.62 total
だいたい3分半ってとこか

Wrote /tmp/src/emacs-23.2/lisp/play/studly.elc
Compiling /tmp/src/emacs-23.2/lisp/printing.el

In org-goto-calendar:
org.el:14017:10:Warning: `view-diary-entries-initially' is an obsolete
variable (as of Emacs 23.1); use `calendar-view-diary-initially-flag'
instead.
org.el:14015:10:Warning: `view-calendar-holidays-initially' is an obsolete
variable (as of Emacs 23.1); use `calendar-view-holidays-initially-flag'
instead.
Wrote /tmp/src/emacs-23.2/lisp/play/yow.elc
Compiling /tmp/src/emacs-23.2/lisp/proced.el
とかでるから
一応並列になってるっぽいけど

>>812 は clean/configure/install の時間も入ってたわ。
裏で軽い作業してたから、目安程度に。

time make -j3 bootstrap
real 7m49.828s
user 13m6.741s
sys 1m2.016s


time make bootstrap
real 13m21.063s
user 12m1.945s
sys 0m57.132s

-j3って何するオプション？

core2 duo 2.16GHz で、ちゃんと計測したら5分半だった。

time make -j3 bootstrap
real 5m29.801s
user 8m21.653s
sys 0m45.636s

>>818
-j3 は、make の時にプロセスを同時に3つ起動するように指定するオプション。

コンパイル速度なんてどーでもいいから他でやってくれ

じゃあ他のネタ振ってよ

>>820
お前が他に行けばいいんじゃね？

誰かvimacsの開発しませんか？

流行らんとおもうわ。

既存のviのマイナーモードなんていくらでもあるんだし、
それを使えばいいのに。努力損だよ。

今思いついたけど、Escをシステム(?)レベルで横取りして
モード切り替えを実装して、コマンドモードの時に
h Ctrl-b
j Ctrl-n
k Ctrl-p
l Ctrl-f
と、キーを変換してアプリに渡せば、もうviの話題は出てこなく
なるだろうから誰か作ってくれ。

>>821
1レスで終了しますた
すまそw

vim をエミュレートしてる vim-mode のvim.el か vimpulse.el
のどちらかがコマンドモードとかインサートモード並びに
テキストオブジェクトとか実装してた気がする。

viキーバインドの再現は、自分でマイナーモード二つ書いてトグルすればいい
どちらかというと欲しいのは、elisp以外の言語のネイティブな実行環境だな
pymacsのコンセプトは好きなんだが、すげー重い

TextMateはマクロにRuby使えるけど、
あんな感じでマルスレ使えるスクリプト言語に対応して欲しい
Emacsユーザーが増えない理由の一つにelispの(.emacsの)
「モダンでない雰囲気」で人を寄せ付けないのがあると思う

るびきち先生が昔elispとRubyスクリプトをスムーズに連動させる、
よくわからないものを作ってたような。

別に「スムーズ」じゃなかろう

別に今更emacsユーザ増えなくてもなあ
それに現状使っててそれほどこまらんしなぁ・・・

増えなければ緩やかに死を迎えるだけだよ

それはない

mozcいい感じ

mozcは超期待外れのダメダメソフトだった

まあ、SKKで十分だしな

しかしSKKは辞書を強化するべきだけどな。mozcよりはまし

いい加減、emacsばりに自由に拡張できる
次世代エディタが出てきてもいいはずなんだけどなぁ。
文法はCライクだとうれしい

>>838
Kateとかどうよ。

auto-complete で html-mode のときに *.rb を開いているバッファの単語を
補完候補にするにはどうしたらいいでしょうか？

dabbrevで解決するのは雑か？

>>841
dabbrevはずっと使っているんですが、同じようなシンプルな使い方が
auto-complete で、できないものかと。

cssのバッファに書いているクラス名を、htmlのバッファで補完とか多用するので
同じバッファからのみという仕様は個人的にはメリットが少なかったりします。

(ac-define-source words-in-rb-mode-buffer
'((init . ac-update-word-index)
(candidates . (ac-word-candidates
(lambda (buffer)
(eq 'ruby-mode (buffer-local-value 'major-mode buffer)))))))
で ac-source-words-in-rb-mode-bufferっていうac-sourceが定義されるから
このac-sourceをhtml-mode-hookでac-sourcesに含めるようにすればどうか

auto-completeのことで質問。
1.3使ってて、
描画のタイミングで補完候補を特定の文字を区切りにばらばらにしたいんだけど、
できるのかな？
ac-inline-showのところに(setq candidate (split candidate))とか入れればいいのかな
とか思ってやってみたけどだめだった

>>842
dabbrevはカレントバッファだけでなく、
開いているすべてのバッファを対象に展開候補を捜す。

たとえば、望みのcssファイルを開いた状態でhtmlを編集する場合、
htmlバッファでdabbrevするとcssバッファからもキーワードを拾う。

特定の範囲に狭めた自作機能もいいけど、
デフォルトの使い方を軽く覚えてみるのもいいと思うんだな。

>>843
ac-define-source をどこに書いたらいいかわからなくて
次のようにしてみたんですが、どうも動いてないようです
auto-completeはdabbrev的な使い方は推奨してないんでしょうかね

(add-to-list 'ac-modes 'html-mode)
(add-hook 'html-mode-hook
'(lambda ()
(ac-define-source words-in-rb-mode-buffer
'((init . ac-update-word-index)
(candidates . (ac-word-candidates
(lambda (buffer)
(eq 'ruby-mode (buffer-local-value 'major-mode buffer)))))))
(add-to-list 'ac-sources 'ac-complete-words-in-rb-mode-buffer)))

>>845
誤解させてしまってすいません
dabbrevは、それがないと仕事にならないというほど使ってます
それでdabbrevにauto-completeの補完窓(？)がついたら、より効率的に
なるのかどうかを試したかったんです

(ac-define-source NAME DEF)で定義されるac-source名はac-source-NAMEの形式で
ac-complete-NAMEの形式で定義されるのはac-sourceだけを対象にして補完を行うコマンドだから
ac-sourceのレギュレーションに合わないものをac-sourcesに設定してる為にauto-complete-modeがエラーで停止してる
なので>>846のac-sourcsを設定してるところを

(add-to-list 'ac-sources 'ac-source-words-in-rb-mode-buffer)

にすれば動く筈

>>844
kwsk

学校の先輩がEmacsはiMacのパクリとゆってたのですが
どんな理由でパクッタのでしょうか。

それ「eMac」だろ。