元スレEmacs Part 34
emacs覧 / PC版 / みんなの評価 : ○
前へ
802 = :
>>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<------
804 = :
>>802
ありがとうございます。期待通りに 暗号->復号されました。
しかし Org-Mode は、UTF-8 以外は 推奨していないのだろうか？ もし、
どの文字コードでも可能なら
(encode-coding-string
(buffer-substring-no-properties beg end)
buffer-file-coding-system)
(org-decrypt-entry も同様に) が筋なのかな
805 = :
>>799
自分のコンピューターのスペックです。
model name : Pentium III (Katmai)
cpu MHz : 551.310
cache size : 512 KB
MemTotal: 384600 kB
Emacs のコンパイルには 2時間位掛かったような、、、 まあコンパイルは
空いた時間にやればいいので
806 = :
>>804
buffer-file-coding-system はファイルの内容によって変わる可能性があるから、
やめた方がよいよ。
たとえば euc-jp-unix なファイルに表現できない文字を加えると、
buffer-file-coding-system が変わってしまい、
euc-jp-unix な時に暗号化したものを復号すると化けてしまう。
とりあえず、一定で大きな coding-system を使っていれば実用上は問題ないと思う。
(utf-8 が適切か？という問題はあるかもしれないけれど、世の中の流れ的には
まあ妥当かと)
ファイル単体として見たときに、平文のところは euc-jp、 暗号化されたところの中身は
utf-8 になっているという気持ち悪さはあるかもしれないけどね。
807 = :
core2 duo 2.16GHz で、-j 2 すると10分ぐらいかな。
809 = :
ここにも格差が…
810 = :
格差があるのに格和や格積がないのは不自然。
812 = :
Athlon64 X2 3800+ (2GHz) で make -j3 bootstrap が 11 分かからないくらい。
814 = :
bootstrapで一番時間かかってるバイトコンパイルのところって並列になるの？
815 = :
やれば分かるだろって話なんですが
EmacsはWindowsでしか使っていないので
UNIXの場合どうなのかなという疑問です
817 = :
>>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
819 = :
core2 duo 2.16GHz で、ちゃんと計測したら5分半だった。
time make -j3 bootstrap
real 5m29.801s
user 8m21.653s
sys 0m45.636s
>>818
-j3 は、make の時にプロセスを同時に3つ起動するように指定するオプション。
820 = :
コンパイル速度なんてどーでもいいから他でやってくれ
821 = :
じゃあ他のネタ振ってよ
822 = :
>>820
お前が他に行けばいいんじゃね？
823 = :
誰かvimacsの開発しませんか？
824 = :
流行らんとおもうわ。
既存のviのマイナーモードなんていくらでもあるんだし、
それを使えばいいのに。努力損だよ。
825 = :
今思いついたけど、Escをシステム(?)レベルで横取りして
モード切り替えを実装して、コマンドモードの時に
h Ctrl-b
j Ctrl-n
k Ctrl-p
l Ctrl-f
と、キーを変換してアプリに渡せば、もうviの話題は出てこなく
なるだろうから誰か作ってくれ。
826 = :
>>821
1レスで終了しますた
すまそw
828 = :
viキーバインドの再現は、自分でマイナーモード二つ書いてトグルすればいい
どちらかというと欲しいのは、elisp以外の言語のネイティブな実行環境だな
pymacsのコンセプトは好きなんだが、すげー重い
TextMateはマクロにRuby使えるけど、
あんな感じでマルスレ使えるスクリプト言語に対応して欲しい
Emacsユーザーが増えない理由の一つにelispの(.emacsの)
「モダンでない雰囲気」で人を寄せ付けないのがあると思う
829 = :
るびきち先生が昔elispとRubyスクリプトをスムーズに連動させる、
よくわからないものを作ってたような。
830 = :
別に「スムーズ」じゃなかろう
831 = :
別に今更emacsユーザ増えなくてもなあ
それに現状使っててそれほどこまらんしなぁ・・・
832 = :
増えなければ緩やかに死を迎えるだけだよ
833 = :
それはない
834 = :
mozcいい感じ
835 = :
mozcは超期待外れのダメダメソフトだった
836 = :
まあ、SKKで十分だしな
838 = :
いい加減、emacsばりに自由に拡張できる
次世代エディタが出てきてもいいはずなんだけどなぁ。
文法はCライクだとうれしい
839 = :
>>838
Kateとかどうよ。
840 = :
auto-complete で html-mode のときに *.rb を開いているバッファの単語を
補完候補にするにはどうしたらいいでしょうか？
842 = :
>>841
dabbrevはずっと使っているんですが、同じようなシンプルな使い方が
auto-complete で、できないものかと。
cssのバッファに書いているクラス名を、htmlのバッファで補完とか多用するので
同じバッファからのみという仕様は個人的にはメリットが少なかったりします。
843 = :
(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に含めるようにすればどうか
844 = :
auto-completeのことで質問。
1.3使ってて、
描画のタイミングで補完候補を特定の文字を区切りにばらばらにしたいんだけど、
できるのかな？
ac-inline-showのところに(setq candidate (split candidate))とか入れればいいのかな
とか思ってやってみたけどだめだった
845 = :
>>842
dabbrevはカレントバッファだけでなく、
開いているすべてのバッファを対象に展開候補を捜す。
たとえば、望みのcssファイルを開いた状態でhtmlを編集する場合、
htmlバッファでdabbrevするとcssバッファからもキーワードを拾う。
特定の範囲に狭めた自作機能もいいけど、
デフォルトの使い方を軽く覚えてみるのもいいと思うんだな。
846 = :
>>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の補完窓(？)がついたら、より効率的に
なるのかどうかを試したかったんです
847 = :
(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)
にすれば動く筈
848 = :
>>844
kwsk
849 = :
学校の先輩がEmacsはiMacのパクリとゆってたのですが
どんな理由でパクッタのでしょうか。
850 = :
それ「eMac」だろ。
みんなの評価 : ○
emacs一覧へ類似してるかもしれないスレッド
- Emacs Part 54 (97) - [92%] - 2023/1/25 17:15
- Emacs Part 44 (1001) - [92%] - 2014/2/8 8:01 △
- Emacs Part 37 (1001) - [92%] - 2011/6/20 19:47
- Emacs Part 38 (1001) - [92%] - 2011/11/29 0:01
- Emacs Part 39 (990) - [92%] - 2012/2/9 19:45
- Emacs Part 33 (1001) - [92%] - 2010/3/9 20:01 ○
- Emacs Part 32 (1001) - [92%] - 2009/12/20 2:04 ○
- Emacs Part 31 (1001) - [92%] - 2009/10/23 10:31 ○
- Emacs Part 35 (1001) - [92%] - 2010/9/19 17:01
- Emacs Part 36 (1001) - [92%] - 2011/3/1 5:02
- Emacs Part 45 (1001) - [84%] - 2014/6/23 9:45
- Emacs Part 46 (984) - [84%] - 2014/12/24 14:15
- Emacs Part 52 (984) - [84%] - 2021/5/13 1:45
- Emacs Part 51 (1005) - [84%] - 2020/3/26 18:30
トップメニューへ / →のくす牧場書庫について