NTEmacs スレッド 3
ttp://anago.2ch.net/test/read.cgi/software/1325573999/
GNU Emacs
ttp://www.gnu.org/software/emacs/ gnupack (cygwn + emacs package)
ttp://sourceforge.jp/projects/gnupack/ GNU emacs(x64)
ttp://hp.vector.co.jp/authors/VA052357/emacs.html NTEmacs JP Project
ttp://ntemacsjp.sourceforge.jp/ CVS
ttp://savannah.gnu.org/cvs/?group=emacs Git
ttp://savannah.gnu.org/git/?group=emacs IME パッチ
ttp://sourceforge.jp/projects/gnupack/downloads/46325/ MinGW でビルド
ttp://homepage.mac.com/matsuan_tamachan/emacs/BuildNtemacs.html FAQ
ttp://www.gnu.org/software/emacs/windows/ntemacs.html EmacsWiki
ttp://www.emacswiki.org/ Mailing Lists
ttp://savannah.gnu.org/mail/?group_id=40 Bug Report
M-x report-emacs-bug RET
GC モジュール総入れ替えしちゃったから、最低でも後一回はプリリリースを
出すはず。
windowsにおいてmmap使われてるファイルに対するアクセス対応がされてないし。
せめて動作確認していて欲しいけど
設定ファイルの構成での読み込み優先が下記と記されてます。
~/.emacs.el(.emacs.elc)
~/.emacs
~/.emacs.d/init.el(init.etc)
~/.emacs.d/init
~/.emacs.el(.emacs.elc) が読み込み優先順位1番なら
C:\emacs\lisp\cedet\ede\emacs.el(emacs.elc)がデフォルトの場合はどうなるんですかね。
ホームディレクトリは、C:\emacs\homeに設定してますので、~\.emacs.d に init.el ファイルを生成すればそれが優先されるのでしょうか？
>
> ~/.emacs.el(.emacs.elc) が読み込み優先順位1番なら
> C:\emacs\lisp\cedet\ede\emacs.el(emacs.elc)がデフォルトの場合はどうなるんですかね。
デフォルトの意味がわからんよ。
CEDETディレクトリがなにか関係あるの？
そもそもどこから起動してる？
cygwinから?それともemacs.exeを直接実行？
cygwinならユーザーディレクトリだろうし
emacs.exe直接起動ならwindowsのユーザーフォルダ。
> ホームディレクトリは、C:\emacs\homeに設定してますので、~\.emacs.d に init.el ファイルを生成すればそれが優先されるのでしょうか？
環境変数HOMEがC:\emacs\homeなのであれば書いてある通りで間違ってない。
レスありがとうございます。駄文に対応してくださり恐縮です。
説明不足でしたので、補足させてください。
私が使ってるNTEmacsは、gnupackのemacs onlyです。
c:\emacsにインストール後の初期状態のパスを示した形です。
起動はC:\emacs\bin\runemacs.exeになります。
>emacs.exe直接起動ならwindowsのユーザーフォルダ
恐縮なのですが、文脈が理解出来てません。原因は私だと思いますが...
追記です。
>環境変数HOMEがC:\emacs\homeなのであれば書いてある通りで間違ってない。
仰る通りで正常に動作しました。
gnupack（emacs only）側からすれば、 C:\emacs\lisp\cedet\ede\emacs.el(emacs.elc)をを触れという事なんですかね。
調べる限り誰もこの事に触れてないので...
CEDET 下の EDE パッケージを使用する時にロードされるファイル。
実際、ディレクトリ ede は load-path に含まれず ede/emacs という
feature 名で参照されている。
ttp://cedet.sourceforge.net/srecode.shtml >
> 追記です。
>
> >環境変数HOMEがC:\emacs\homeなのであれば書いてある通りで間違ってない。
>
> 仰る通りで正常に動作しました。
> gnupack（emacs only）側からすれば、 C:\emacs\lisp\cedet\ede\emacs.el(emacs.elc)をを触れという事なんですかね。
> 調べる限り誰もこの事に触れてないので...
12の補足通り関係ないファイル。
むしろなぜそのファイルを見つけたのか気になるが・・。
とりあえず~/.emacs.d/に
init.el
がないなら空ファイルを作ってそこに自分で追記していくのが正しい。
ありがとうございます。今のところ順調に設定等出来ています。というか夢中になって全く寝てない...
楽しいですよー
>むしろなぜそのファイルを見つけたのか気になるが・・。
本に記載されてるファイルを検索したら、あったんですよー。無ければ悩む事無かったんですが。
wl のインストールは ELPA でできるよ。下のページに書いた。
ttp://www.emacswiki.org/emacs/WanderLust#toc2 Vimを無理に肥大化させるよりは、
素直にEmacsで拡張した方がスマートで便利だった
日本語いれてると落ちるやつ。
上記環境で、executable-find 関数がありません。以下がありますが、代替されてたりするのでしょうか。
元の挙動知らないために、Messagesバッファを見ても、よくわかりません。
Possible completions are:
executable-interpret
executable-self-display
executable-set-magic
describe-function してみたら
ありがとうございます。
これからダメもとで、wl実装にチャレンジです。
原因教えて欲しいです。
(require 'egg)
;; GitフロントエンドEggの設定
(when (executable-find "git")
(require 'egg nil t))
Eggをインストールして、git使おうと思ったけど、実際使うには何すればいいんだ。
本には、C-x v s とか書いてあるけど、やったらこれ
"No VC backend is responsible for C:\emacs\bin/"とか出てきて意味不明。
僕の頭悪さがこの自体招いてることは承知してるけど、いくらなんでも、摺合せの情報が多い。さすがにキツイよ。
あと ででたエラーはどんなエラーなの？
の回避方法って git がなけりゃロードしない、あと egg ロード中にエラーが起きても無視するってコードだから
多分なんの解決にもなってない可能性が高いぞ
私の認識しているそもそも間違ってるようです。（今のところ全てが...）
私が使えないと判断したのは、auto-installを実装して、install-elispで、
git clone git://github.com/wanderlust/apel.gitを実行出来なかったからです。
eggを実装すれば、出来るものと思ってました。
今回はとにかくwlを使いたいのが一番ですので、git shellを使って、apel, flim, semi, wanderlustをダウンロードして
apelはmakeit.batを実行し、~/.emacs.d/elispにインストールされました。
film, semi, wanderlustは単純にelispディレクトリにコピーしただけとなってます。
もう Wnn とか Canna 使ってる人いなそう
とりあえず失敗したときは出てきたエラーをそのまんま貼り付けたほうがコメントもらえると思う。
以下はどうなってるの？
・(executable-find "git") を *scratch* バッファで評価して nil が返ってくる？
→ NTEmacs 側の exec-path の設定が足りてない
・(locate-library "egg") を *scratch* バッファで評価して nil が返ってくる？
→ egg をインストールしたディレクトリが load-path に含まれていない
自分は cygwin の git でわざわざ egg いれなくても標準の vc から git 使えてるけど
Windows ネイティブのを使おうとかおもうと egg が必要になるんかねえ。
wl はわざわざコンパイルしなくても el 入ってるディレクトリを全部 load-path に入れてっても使えたかもしれん。
あと関係ない話だけど実装って言葉の使い所がおかしい気がする。
「wl を実装する」とか「auto-install を実装する」だと仕様に則ってそのプログラムそのものをコード化する意味に聞こえるよ。
単に設定してるだけだよね？
指摘ありがとうございます。また、こんな私に親身になってくれてありがとうございます。
指摘された内容を今からさっそく検証します。
実装という表現が誤解を招く恐れがあるこを指摘してくれてありがとうございます。
「設定」ですね。
なんか皆さん、優しくて泣きそうです。まじで嬉しいです。
>→ NTEmacs 側の exec-path の設定が足りてない
nilが返ってきました。
>・(locate-library "egg") を *scratch* バッファで評価して nil が返ってくる？
>→ egg をインストールしたディレクトリが load-path に含まれていない
c:/emacs/home/.emacs.d/elisp/egg.elcが返ってきました。
したらば、git の実行ファイルの位置を emacs に教えてあげる必要があるから
・git.exe がある場所を exec-path に追加するか
・環境変数 PATH に追加するか
・git.exe へのフルパスを egg-git-command に設定するか
の何れかをしてやればいいんじゃないかな。
この手の中でプログラムを呼び出すパッケージなんかは NTEmacs の場合は特に
パス絡みで変なことになりがちだからまずそこチェックした方がいいと思う。
ありがとうございます。まずは頭クリアにするために、Emacsを再インストールして一個一個やりたいとおもいます！
ImageMagick-6.8.9-3がMinGW-w64でビルドできずにハマりました。
ImageMagickのバグレポートにパッチを出しときました。
ttp://www.imagemagick.org/discourse-server/viewtopic.php?f=3&t=25778 お急ぎの方はどうぞ。そのうち取り込んでもらえると思いますが。
msvc-inval.h と msvc-nothrow.h が無いといわれて失敗。
gnulibから引っ張ってきて $OPTLIBS64/include に置いて再トライするも、
今度は O_CLOEXEC, F_DUPFD, F_DUPFD_CLOEXEC, F_GETFD, FD_CLOEXEC
が未定義だと怒られる。。。
ヘッダファイルか何かいじって適当に定義してやればいいのかもしれませんが、
もしかして何かおかしい？？？それともこういうもん？？？
はずなので何かおかしいです。
configure 実行時に
checking whether dup2 works... (cached) yes
って出てます?
checking whether dup2 works... no
になってるならmsys.batじゃなくmsysのbashかshかを直に起動して作業したとか。
ImageMagick は 6.8.9-4 が出てますね。そのパッチが取り込まれたのかな。
ありがとうございます。
コケたのは lib/fcntl.c です。もしかしたら lib/dup2.c もコケるのかもしれませんが。
configure 実行時には、
checking for fcntl... no
とか
checking whether dup2 works... no
って出てますね。。。
msys.bat は使ってるんですが、、、何がいけないんだ。。。
ImageMagick 6.8.9-4 は私のパッチとは違いますが修正されてます。
スンナリとビルドできました。
うーん、msys.batで設定されてるはずなんですが環境変数のMSYSTEMに
MINGW32かMINGW64が設定されてますか?
configureでこれ見てmingw用の設定(nt/mingw-cfg.site)が読み込まれます。
MSYS、cygwinの順にパスを設定していても
同じ症状になった覚えがあります。
まさしくそれです。ドンピシャです。
msys.bat は起動前に環境変数MSYSTEMが設定されていると引き継ぐみたいで、
その状態だと ImageMagick の configure がおかしくなる、ということがあったので、
ワザワザMSYSTEMをカラにしてビルドしてました。
ImageMagick の configure は uname を見て動作を決めているようです。
MSYSTEMに変な設定がされていると uname が、その変な設定を返すんですよね。
で、カラにしておけば uname がまともになって、ImageMagick の configure は成功したもので。
MSYSTEMにMINGW64を設定して emacs の configure からやりなおしたら、
何の問題もなくビルド成功しました。64 bit の emacs が起動できました。
ありがとうございます。感謝感激です。
ありがとうございます。
パスは msys.bat 起動後に手動で再設定してまして、
cygwin や Windows のパスはすべて削除、
MinGW-w64, MSYS, ImageMagick だけに通してからビルドしていました。
MSYS の pkg-config へ先にパスが通っていると、
gnutls や ImageMagick が見つけられなくて、無効になってました。。。
$OPTLIBS64/bin にある pkg-config へのパスを先に通すようにするか、
環境変数 PKG_CONFIG_PATH に $OPTLIBS64/lib/pkgconfig を設定しておくか、
いずれかすると有効にできました。
あ、ImageMagick も pkg-config 使うみたいですね。
こっちもビルドやり直した方がいいかな。。。
emacs-24.3.92 出てますね。パッチは 24.3.91 用のもので当たりました。
ntemacsインストール後、lookup-1.4+media-20130903.tar.gz
をインストールするには、どうすればいいのですか？
また、ntemacsからcygwinを起動するにはどうするのですか？
(setq shell-file-name "bash")
(setq shell-command-switch "-c")
あたりでいけるっしょ
M-x shell
でいけるはず
このスレで出た設定をまとめてる人がいるから見てみるといいかも。
ttp://www49.atwiki.jp/ntemacs/ wiki だけど設置者しか編集できないようになってるのが玉に瑕
したらemacsがおかしくなりました。
長いパス名を持つファイルやフォルダは、まともに扱えないみたいですね。
Note: file is write protected とか出て書き込めないとか、
（メモ帳なら書き込めるのに）
Directory hogehoge inaccessible or nonexistent とか出たり、
（エクスプローラでは見えてるのに）
dnd-open-local-file: Can not read file:C:\ほげほげ とか出たり。
（メモ帳では読み書きできるのに）
たぶん src/w32.c で MAX_PATH を使って配列確保しているからかと。
NTFS なら MAX_PATH を超えるパス名のファイルも作れるんですけどねぇ。
誰も困らん。
テストケースは作ってないけど、とりあえず報告してみました。
その通りだけど対応するのは大変すぎなので優先度低いよ、
てな感じの反応がありました。
後で気が付いたことをば。
ファイル名に日本語が入っていると1文字でcharを2文字分消費しちゃうので、
余計に制限に引っかかりやすくなります。というのがemacs-24.3までの状況。
これが emacs-24.3.92だと日本語1文字でもwchar_tを1文字消費で済むので、
かなり改善されてます。
今まで使ってたgnupack版のemacs-24.3とはディレクトリ構造が全然ちがいますね。
これはgnupackのビルド方法が違うからなのか、
24.4でディレクトリ構造が変わることになったからなのか。
おかげで、そのままだとmewのインストーラが動きませんでした。
mew.iniをいじって、BINDIR, ELISPDIR, INFOPATHあたりを指定すれば
使えるようになりましたけど。
(というかunix系OSと同じになった)からですね。etc/NEWSの
* Changes in Emacs 24.4 on Non-Free Operating Systems
に書いてあります。
確かに書いてありますね。
ありがとうございます。
同じ手順でやったハズなんですが、Imagemagick がうまく動作せず。
scratch で (imagemagick-types) を評価すると nil が返ってくるんだけど、
imagemagick-enabled-types には、いっぱい入っている、という変な状態。
いろいろ調べたら、なぜか
libMagickCore-6.Q16-2.dllとlibMagickWand-6.Q16-2.dllが
mingw-w64 32bitのlibgcc_s_sjlj-1.dllに依存してました。
こいつをbinに入れたらちゃんと動くようになりました。
mingw-w64 64bitだとlibgccの類には依存しないように作れてるんですけどね。
なんでだろ。
(require 'helm-config)
この'load-path 'helm-config の ' をそっくりでありながら違う文字に差し替えて
インストール方法紹介してる初心者狩りのサイトに引っかかったwww
畜生まんまとやられたぜ
まだpretestでるんかな
ttp://lists.gnu.org/archive/html/emacs-devel/2014-08/msg00232.html 何が変わったのかよくわからんが
今更何も変わらんぞ
細かいバグ修正だけだ多分
mingw-32のサウンドライブラリとヘッダは見つかるのですが、64ビット版が見つからず、mingw-64入れただけではコンパイルに失敗してしまいます。アドバイスいただけないでしょうか？
やりかた教えてほしいな
しばらく前にemacs-24 branchやtrunkに入った
ttp://lists.gnu.org/archive/html/emacs-diffs/2014-09/msg00105.html の修正を加えるとpretest 24.3.93でも他のライブラリなどを用意しなくても
とりあえずsound support有りのものが作れました。
但しこれだけだとファイル名が日本語のファイルが再生できないので
ファイル名が日本語のものも再生したいなら
ttp://lists.gnu.org/archive/html/emacs-diffs/2014-09/msg00126.html の修正も必要なようです。
それだと同じファイルを他者と編集していた場合、編集内容が消える可能性があるので、使用NGになりそうな感じです。
ttp://d.hatena.ne.jp/tand2me/20110303/1299178771 そんな事故が起きそうな使い方するんだったらバージョン管理システムの導入の稟議書でもだすか
おとなしく windows で排他制御サポートしてるエディタの Emacs モードでも使ったほうがいいと思う。
Emacs は最初にがーっとファイルの内容をバッファに読み込んでファイルは閉じちゃう仕組みになってるからOS の排他制御とは相性悪いのよ。
そういうのがやりたければ vc-mode 使って RCS なりもっと近代的なバージョン管理システム使ってねって感じになってる。
Emacsをはじめ、マルチプラットフォームのテキストエディタでは、あまりメジャーではない機能なんですね。
Windowsだと結構ありますが。。。
今後Windows以外にMacやxUbuntu辺りを使う予定があるので、xyzzyからEmacsに乗り換え検討していたんですが・・・
家ではEmacs、仕事ではxyzzyというのも違和感ありますし（仕事ではWindows一択）
24.4からEmacs同士に限りロックするようになった
他のアプリとは排他制御されてない (Emacsで編集中のファイルを開ける)
それはxyzzyも一緒
そこら辺のエディタは開発作業に用いられることが多いから、OS毎にバラつきある上機能的にはシンプルな排他機構より
もっと多機能なバージョン管理システムに依存していくのはしかたないのかもね。
xyzzy は emacs のロックファイルを使った排他制御じゃなく Windows 自身のロック機能つかうから
xyzzy 同士だけじゃなく他のどのプログラムに対しても有効になるよ。
排他ロックにすれば Emacs からも開けなくなるし、
共有ロックにすれば読み取り専用ファイルになってないのに書き込もうとすると Permission denied がちゃんとでる。
なるほど…オプションで変更しないと有効になんないんだな
実際やってみればわかるけど、ディスク上のファイルがEmacsのしらないところで書き換わると
セーブするとき警告が出るから、内容を壊したりすることは無いよ。
Emacs 18のころからそう。Windows版もおなじ。
global-auto-revert-modeも24.4からLinuxでいうinotifyに対応したから
ポーリングなしで一瞬で反映されるようになった
日本語入力中にたまにEmacsが落ちてしまう。。。
パッチが24.3.90用だったので、こっちのソースにパッチを当てても一緒。
では、その前の24.3でも前スレ499氏のパッチを当ててビルドしても、やっぱり日本語入力中に落ちてしまう。
(setq ime-enable-reconversion nil)
(setq ime-enable-document-feed nil)
してもやっぱりたまに落ちる。同じような問題に遭遇して解決したかたがいれば情報いただけませんか？
前スレ499やgistにパッチ置いてるrzl24oziは私ですが私のとこでもたまに
落ちます^^; 原因わかってません。すみません。
#わからんなら黙ってろっていわれるかもしれませんが
ビルド後.exeにpeflags --cygwin-heap=2048してみるとか、
gistのREADME.txt最後に書いたけどcygwin64ならconfigure時に
LDFLAGS='-Wl,--stack,0x400000'を指定してみるとかすると
落ちる頻度が下がったような気はします。気のせいかも。
ttp://www49.atwiki.jp/ntemacs/pages/42.html shell-command-to-stringで起動するコマンドを絶対パスで指定する際のドライブレターの書き方で、
引数が読み込める場合と読み込めない場合があるのを知らなくて結構嵌りました。
例えば、こんな感じ。
(shell-command-to-string (concat "c:/gnupack/app/cygwin/cygwin/bin/ls " (shell-quote-argument "c:/"))) ; エラー
(shell-command-to-string (concat "/c/gnupack/app/cygwin/cygwin/bin/ls " (shell-quote-argument "c:/"))) ; 動く！
gnupack12.10で使ってますが、私の場合は、日本語と英語の切り替え中に指がからまると落ちます。
(英語キーボード使用)。日本語モードと英語モードの切り替えの一瞬の空白に文字がやってくると死ぬのかな〜
なんて思ってるんですが、はずしているかもしれません。
参考になれば幸いです。
ttps://github.com/chuntaro/NTEmacs64 ここでも見とけ
ttp://emacsbinw64.sourceforge.net/ こんなのもあった
ありがとうございます。
ttp://lists.gnu.org/archive/html/emacs-devel/2014-10/msg00376.html 64bit対応になっていてそのままインストールできると期待したい
>日本語周りが・・・
具体的にどういうこと？
ありがとうございます。これから32bitのC:\cygwinを別の64bit PCに入れようと思っていて、質問させて頂きました。
回答ありがとうございます。
不具合等はやはりありますか？
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
その前はmeadow 1を使ってた。
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
ttps://gist.github.com/rzl24ozi うーすみません、このスレにもいらっしゃる有名な方でした
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
・でかいファイルを扱えるようになる
・60bit位の数値を扱えるようになる
・無駄に余っているメモリを使ってくれる
…位しか思い浮かばない。なんかほかにもあるの？
っで、cygwinの64bit版インストールするのと
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
emacsの理念からすると不自由なIMEに対応する理由などないSKKを使え
みたいなノリなのか
今頃気付いた…
え？マジで！
正直入力データをぶっこ抜かれそうで躊躇してたけど、後で試してみよ
ttp://sourceforge.jp/projects/gnupack/forums/22824/34508/ それは gnupack の IME パッチ当てたバージョンでしょ？
素の NTEmacs だと特になんの設定もなく使えるよ。
ただしフォントの設定とかできるわけではないから微妙にズレが気になるかもしれないけど。
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
emacs-mozcってWindowsではやっぱり使えないのかな
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
日本語以外の言語でもIME使うと思うんだが
次に出るwin版emacs24.4を配布時そのままいじらずインストールするのと
どちらが危険でしょうか？
まず真面目に詳細に回答してあげなよ
俺はcygwin使ったこと無いから何とも回答できないけど
mingwでコンパイルした
に詳しく回答してあげて
私は詳しくないから
パッチの内容みてないんだけどあれって逆に日本語に特化した対応になってたりしてないん？
cygwinの64bit版の方が危険だよ
その根拠を具体的に詳細に解説お願いします
これからcygwinを使う他の人々にも有益だからよいじゃないか
俺もcygwinのことよく知らなうし
なぜ？
それをWindows上で動かそうというのだから、ちょっと無理してるところがあるはずだ
結局は「危ないところがあちこちあるがひとまず動けばいいや」で実装することになる
だからWindowsネイティブで動くEmacsのほうが脆弱性はあるんじゃないか
その点cygwinは一旦*NIXに近い環境を作ってその上で*NIXアプリを動かそうという発想だから
アプリそのものは「俺は*NIXの上で動いてるぞ」と思いながら動く
Windowsネイティブ版と比べたら脆弱性が少なくなる
ところがcygwin自体は「動けばいいや」で実装してるから、結局トータルでは「脆弱性あるじゃん」ってことになるのだ
特にcygwin64はまだ枯れてないので、脆弱性が一際残っているはずだ
ソース眺めたこともないエンドユーザが想像と邪推と思い込みだけで無理矢理理由作ってみましたヨ
「危険」の定義を具体的に詳細に解説お願いします
レポ頼む
「ぶっこ抜かれそう」かどうかも含めて
まだ試してなかった、後でちゃんとやるよ
けど、ぶっこ抜かれそうかどうかなんて分かるかよw
ttp://www.google.co.jp/ime/technology.html > Google では学習した内容を一切収集していませんので、安心してお使いください。
って言ってんのに、それを覆す証拠を掴むなんてどんな凄腕ﾊｶｰだよ
パソコンに不具合等発生する危険性だろ
>特にcygwin64はまだ枯れてないので、脆弱性が一際残っているはずだ
最新版のcygwin64では脆弱性とか、改善されてないのですか？
後はに詳しい回答を希望したい
確かにGoogleIMEだとパッチ無しで入力出来るな
ただしXでいうところのover the spotだしフォントサイズも合ってない
IMEパッチ関連を少し調査した事あるけど、現状のNTEmacsは
IME入力コールバック内でデフォルト処理をせずにリターンしちゃってるから
MS-IMEだと入力中の文字が表示されない (Enter押せば一気に表示される)
GoogleIMEはその辺を上手い事回避してんだろうね
ただこの状態で良ければ数行のパッチでMS-IMEでも入力可能に出来る
しかしIMEパッチってのはon the spot(要するにアプリ内にきちんと表示される)
にすべきもんだからなぁ
ttps://productforums.google.com/forum/#!topic/ime-ja/tgXztpe84ok そのコメントで書いてあるbreak→goto dfltにする修正だけどbreak自体は
5箇所あるから数行って事だった
もしかしたら最後だけやればいいかもしれないけど
途中のはエラーだから律儀にgot dfltしなくていいかと思いました。
もうソースを取り込んじゃって欲しいよ
ソレ俺
メインエディタはxyzzyだけど、xyzzyでは手間かかる時だけNTEmacs起動して対応してる
たまに起動するだけだしWindows上で動くだけでも御の字だから脆弱性とかどうでもいいな
ttp://sourceforge.jp/magazine/14/10/23/051200 > 改行コードを一切認識しない上にフォントなどの設定を立ち上げる度に初期化する
俺の環境ではそんなことはないんだが・・・
ファイルを一旦バッファに全部取り込んでから処理するってポリシーだから
grep がそのまんま取り込まれるってことは難しいんじゃないのかねえ。
はいはい、メモ帳でも使ってなさい。
多分普通の grep に比べるととてつもなく遅いけど、lv? とやらを入れなくても色んな文字コードの日本語ファイルを検索できるよ。
あれの moccur-grep って grep 不要だったはずだよね。
なんと！知らんかったから調べてみたら、遅過ぎて評判悪いな…
やっぱりelispオンリーは厳しいか
Emacsってインスコするともれなく色々なexeが付いてくるけど、
それにgrepとdiffを含めてくれればいいだけなんだよね
やっぱ表示できるだけじゃ使いにくいよ
マルチストロークコマンドに対応させないとさ
他のOSでも同じなのにいつまでこんななのかね
ttp://sourceforge.net/p/emacsbinw64/wiki/Build%20guideline%20for%20MSYS2-MinGW-w64%20system/ もちろんそうしてるけど、内蔵しててほしいなという話し
ttps://github.com/chuntaro/NTEmacs64 こっちの方がわかりやすい
たぶん最初に言い出した人は印象論でしか言ってないと思うから、いくら尋ねてみても返ってこないと思うよ
詳細尋ねてもどうせ無知だから返事のしようもないんだろ
「冗談だったスマソ」の一言も言えないやつはほっとこうぜ
でさ。自分も気になってググってたら
むしろ cygwin 32bit + emacs 24.4 で落ちるという話があるみたいだ
ttp://cygwin.1069669.n5.nabble.com/bzr-emacs-24-4-50-1-crashes-when-using-auto-revert-tail-mode-td109406.html 原因は cygwin 32bit 側にあるってことになってる
ttps://cygwin.com/ml/cygwin/2014-06/msg00406.html ただ、俺英語がさっぱりダメなんで、結局バグは取れたのかどうかも読めてなくて
もし英語が読めるならオチだけでも教えてほしいぐらい
正直、今はcygwinで動かすメリットは皆無と言ってもいいと思う
むしろパスの扱いがおかしなことになるデメリットがある
cygwinで動かせばコマンドを一々落とさないで済むのはいいかもしれないけど
どう考えても冗談じゃないだろ
誰でも気になることだし、
しかし、cygwinってかなり以前より不具合や互換性（プログラミング関連で）の問題であれこれ言われているのに、
なぜこんなに改善・改良がなされないのが誰もが疑問に思うことだろうに。
Emacsの公式ビルドでWIN64bit版を出していないのが問題だろうに
良識ある人ならWIN64bitでの動作の確認位してリリースするものだろうに
|:::::::::::::;;;ﾉ
|::::::::::( 」 ＜ age書き込み全部同じ奴だろｗ爆釣りだな
ﾉﾉﾉ ヽ_l
,,-┴―┴- 、 ∩_
／,|┌-[]─┐| ＼ ( ﾉ
/ ヽ| | 池 | '、／＼ / /
/ `./| | 沼 | |＼ /
＼ ヽ| lゝ | | ＼__/
＼ | ￣￣￣ |
⊂|＿＿＿＿__|
|l＿l i l＿l |
| ┬ |
無駄な知恵をつけさせてしまったな、すまん
64bitへの対応及び調整の途上にあるからだと期待したい。
|:::::::::::::;;;ﾉ
|::::::::::( 」 ＜ ありゃsageを覚えてしまったか
ﾉﾉﾉ ヽ_l 無駄な知恵をつけさせてしまったな、すまん
,,-┴―┴- 、 ∩_
／,|┌-[]─┐| ＼ ( ﾉ
/ ヽ| | 池 | '、／＼ / /
/ `./| | 沼 | |＼ /
＼ ヽ| lゝ | | ＼__/
＼ | ￣￣￣ |
⊂|＿＿＿＿__|
|l＿l i l＿l |
| ┬ |
emacs-24.3-bin-i386.zip 19-Mar-2013 11:43
という過去を考えると
emacs-24.4.tar.xz 21-Oct-2014 04:01
だから29日頃になるんだろうなぁ
レシピも材料もあるんだから自分で作ればいいわけだが
IMEパッチをあててないとIMEの状態を意識させられて不便
ここだけはquailの方がちょっとましなんだよなぁ
quailのインタフェースでIMEのエンジンが標準で使えればいいのに
> quailのインタフェースでIMEのエンジンが標準で使えればいいのに
まさにこれ
Emacs的にはquail→何らかのライブラリ(exe？)→MS-IMEってなればいいけど
そんな事出来んのかね
ttp://lists.gnu.org/archive/html/bug-gnu-emacs/2014-10/msg01096.html Eli があってたのがすげーなーと思う。
できると嬉しい
Google CGI API for Japanese Inputを使ってみた人とかもいそうだけどなぁ
Google CGI API for Japanese Inputに対応するのは技術的には全然可能だろうね
ただ入力内容が完全にだだ漏れなんで、常用したくないな…
view-mode を適用しているバッファで skk を起動すると、C-p が効かなくなり、かつ、 view-mode のキーマップも skk にとられてしまい、快適な移動ができなくなります。
NTEmacs 24.3 までは、
ttp://homepage1.nifty.com/blankspace/emacs/view.html に記載されている方法で view-mode を優先できたのですが、24.4 ではそれが効かなくなりました。
view-mode 中に skk を起動すること自体がおかしいといえばそうなのですが、isearch や occur などでどうしても日本語を使いたいことがあり、そのたびに skk をつけてきってするのが煩わしいです。
皆さんはどう対応されていますか？
が実行されるとたまに表示がおかしくなりますね。
・・・もしかすると、これらの原因は emacs ではなく ddskk にあるかもしれないです。
emacs 24.3 までは 7月にアップロードされた ddskk を使っていたのですが、24.4 を設定する際には 10月19日にアップロードされた ddskk を使っております。
skk使ってるけどC-pは全く使わないから問題が良くわからん…具体的な手順を教えてほしい
あとNTEamcs固有の問題ってことじゃなくて、Linuxとかでは未確認ってことかな？
ありがとうございます。
C-p の問題はこちら
ttp://kenkov.hatenablog.jp/entry/20110507/1304778289 です。
previous-line をしようとすると、バッファはRead-only ですよ！と怒られます。
ソースコードを弄くるのは怖かったので、記載の対応は試しておりません。
Linux 機はもっておりません。
すみません。
思い切って自分でやってみたら候補が5個しか取れない
これだけでは使い物にならないw
なるほどそういう事か。とりあえずLinux版でも再現する
対応方法という事でもないけど、
(setq skk-delete-implies-kakutei nil)
としてるから、前の候補を選択する時もBS(C-h)を使ってC-pは全く使わないようにしてる
これもNTEmacs固有ではなさそうだけど再現出来ない
たまにっていう事は何か条件があるんだろうね
確実に再現出来る方法が分かったら試してみたいけど
(interactive "*p")
を
(interactive "p")
にする。
詳細にありがとうございます。
ご紹介いただいた方法で対応したいと思います。
(ちなみに、view-mode のキーマップ、例えば w でのスクロールや e で view-mode を抜けるなども skk にとられますが、こちらはどのように対処されていますか？度々すみません。)
fill については、これで文章が壊れたりするわけではないので、問題ないです。
ありがとうございます。
Eliって何ですか？
C-pはで対処できそうだ
ただ w や e はそもそも(interactive "p")だしどうにもなりそうにない
単にskkをオフってから入力するしかない
Eli Zaretskii
とりあえずリクエストだけ送ってみたら確かに5個しか取れないな
単なる実験でやる気が無いのか、変換候補数を指定するパラメータが別にあるのかもしれない
interactive の ”*” ってリードオンリーのときにエラーを出すシグナルなのですね。勉強になります。
w 等は無理なのですね、ありがとうございます。
Occur 等を抜けるときに skk を自動的に切れるようにトライしてみます。
懇切丁寧にありがとうございます。
標準のIMEは変な変換候補が出る。長期的に利用するのは無理そう。
anthyはちょっと遅い。でも一番まともか。でもhelmの検索入力が変。
今、ibus系をなんとかできないか調査中。
とりあえずLinuxのIMEに接続してみようとしているところ。
まぁ慣れればddskkで十分実用的だけどね
Gnus+ddskkで仕事のメールもさんざんやり取りしてるしw
ちなみにibusはD-Busをベースにしてるから、Windowsで同じ事をしようとすると
D-Busサーバーをインストールしないといけなかったり、面倒そうな気がする
結構、Windows側でもテキスト打つから、MS-IMEに操作が似ているIMにしたい。
WindowsでもSSKFEPとかいうの使う方法もあるかと思ったけど、ダメそう。
ibusは、cygwin portsにibusとibus-anthyがあるのを見つけた。これが使え
なかいと調べているのけどうまく動かないので、まずはibus.elでLinuxに
接続して使ってみようかと。
したらできた。設定は以下を参考とした。
ttp://homepage1.nifty.com/~kdo/cygwin.html#anthy init.elの最初に以下の設定を入れるのがミソ。
また、いくつかの設定はコメントにする必要があるかも。
(let ((dir (expand-file-name "~/../app/emacs/site-lisp")))
(if (member dir load-path) nil
(setq load-path (cons dir load-path))
(let ((default-directory dir))
(load (expand-file-name "subdirs.el") t t t))))
cygwinのプロセスをみると、dbus-daemonというが起動している。
恐らく、ibus-daemonから起動しているのではないかと思う。
Cygwin/Xを起動して、ibus-setupをするとIMEを指定する画面が開くん
だけど、何も表示されない。まずはこの辺の解決から。
dbus-daemonは、ibus-setupすると立ち上がるようだ。
以下を読むと、Emacs23.1以降がD-Busに対応したとのこと。
ttp://dev.ariel-networks.com/wp/documents/aritcles/emacs/part12 NTEmacs64でも以下は実行できるけど、後者はnilが返ってくる。
(require 'dbus)
(dbus-list-known-names :session)
Linuxで動くemacsは沢山サービスが返ってくる。この辺からか。
NTEmacs だとコンパイル時に HAVE_DBUS が定義されないだろうし。
cygwin 版だともしかしたら出てくるかも？
fakecygpty 改造してた時も思ったけど対応してない場合って容赦なく nil 返してくるのね。
ibusもdbusも仕組みをよくわかっていないから、いろいろ調べながらだなぁ。
ttp://www11.atwiki.jp/s-irie/pages/21.html のことだとしたら python スクリプトの ibus-el-agent が ibus-daemon との通信を担当してて
ibus.el 自体は dbus も ibus も直接は触ってないみたいだね。
やはり64bit対応IME対応になるのだろうか？
今のところ特に問題は感じないなぁ。
NTEmacs64の手順通りMSYS2でビルドしたら、HAVE_DBUSは1になってる。
その上で、(dbus-list-known-names :session)はnilを返すけど。
ttp://www.geocities.jp/home_page22/xyzzy/lisp.html にある、vertical-cursor-line.lを移植する場合、他に、
encap.l
WinSDK.l
api.l
winapi.l
も移植すれば、NTEmacsでも列カーソルが実装できるのかな？
あと、関数や#ifの折り畳みとかもできるようにしたいです。
Emacs24.4+IMEパッチのビルド問題ないんですね。やってみるか。
素のEmacs24.4で行けるんであれば、それも魅力ではあるのでもう少し頑張って
みる。
ibus-setupでanthyを登録することができた。ibus-modeも起動でき、emacsの
バーにIBusと表示される。ibus-minor-modeが動いているようだ。
ただ、以下のメッセージが表示される。
IBus: Couldn't receive data from agent.
恐らく、ibusの通信がうまくいっていないのだと思う。今ここ。
折りたたみは hs-minor-mode とか hideifdef で出来るけど
マウスクリックで出来るようにするには細工が必要だったかと
やってくれる拡張もあった気がするけどわすれたな・・・
列カーソルだけど、xyzzy のは API 呼び出ししてるみたいだからそのまま移植しても無理じゃないかね。
NTEmacs は DLL 直接呼び出しは今のところ出来ないし。
ibus-el-agentのテストからだな。ibus-el-agentは動いているけど、相手先
との通信がうまくいっていないのだろうか。テストの仕方がわからん。
13:16:29 message: Couldn't receive data from agent.
そもそもlinux側で ps -ef | grep ibus とやるとibus-anthy/engine/main.pyが
動いているけど、cygwin側では動いていない。誰が動かすプロセスなんだろう？
わからないことだらけ。
ttp://homepage1.nifty.com/blankspace/emacs/view.html を参考に、skk-mode-hook の設定も加えたらうまくいきました。
(add-hook 'view-mode-hook
'(lambda ()
(setq minor-mode-map-alist
(delete (assq 'view-mode minor-mode-map-alist)
minor-mode-map-alist)
minor-mode-map-alist
(cons (cons 'view-mode view-mode-map)
minor-mode-map-alist))))
(add-hook 'skk-mode-hook
'(lambda ()
(when (assq 'view-mode minor-mode-map-alist)
(setq minor-mode-map-alist
(delete (assq 'view-mode minor-mode-map-alist)
minor-mode-map-alist)
minor-mode-map-alist
(cons (cons 'view-mode view-mode-map)
minor-mode-map-alist)))))
マルチストロークキーコマンドに対応しないだけなら我慢できると思ってた
でもIMEの状態が表示されないんじゃきつ過ぎる
ibus-anthy動いていないと思ったら、cygwinのpsがプロセスの引数を表示
していないだけだった。pythonの引数として動いているみたい。
ibus-el-agentもLinux側の変換時のログとってcygwin側に投入したら、
漢字変換していることが分かった。
process_key_event(1, 97, 0x0, None, None)
(ibus-update-preedit-text-cb 1 "ああ" 2 t 'underline 1 0 2)
(ibus-process-key-event-cb 1 t)
process_key_event(1, 32, 0x0, None, None)
(ibus-update-preedit-text-cb 1 "嗚呼" 0 t 'underline 1 0 2 'background 13158640 0 2 'foreground 0 0 2)
(ibus-process-key-event-cb 1 t)
つぎは、ibus.elがなぜibus-el-agentをうまく動かしてくれないかを調べる。
linux側との違いは、ibusのバージョン。cygwinの方が1.5系で新しい。
以下のエラーは解決した。これはfakecygptyを通していなかったからだと思う。
IBus: Couldn't receive data from agent.
ttp://epian-wiki.appspot.com/wiki/Memo/20111002054049/ibus-mozc%E3%81%A7Emacs%E7%94%A8%E3%81%AEmozc-mode%E3%81%8C%E6%8F%90%E4%BE%9B%E3%81%95%E3%82%8C%E3%81%A6%E3%81%84%E3%81%9F%20on%20Gentoo でもcygwinでmozcをコンパイルできない。
64bit対応で且つIME使用可能になっていて欲しい
なぜなら公式はソースをそのままビルドするだけで、そのままだとIME対応はされてない
(中途半端な実装がされたまま放置されている)
バグレポートが上がっているわけでもないので、Emacs開発者は日本語IMEに関
する処理は完璧で、日本人ユーザーは皆ハッピーだと思っているよ。
思いもしないんだろうね
さらにIMEパッチはIMM32を使った古い実装だから、いつかは使えなくなる時が来るだろう
数年以内にはそんな事にはならないだろうが、いつかはTSFを使った実装に移行する時が来る
そん時が最後のチャンスだろうねw
GNUに参加してEmacsを構築してくれるネ申のような人いないのかな？
そうすりゃ、windowsユーザーの気持ちも分かってくれて、
早期にIME対応になっていると思うのだが。
マジで文句言ってないで自分で行動を起こせよ
単に指食わえて待ってる奴の泣き言なんて聞きたくねーんだよ
ここ、ちんぴらやちんぴらもどきがむやみに屁をこくところと勘違いするな
物の言い方を知らん、場違いを知らん輩は恥を知れ、
公衆の面前で醜態を晒し空気汚染を繰り返すことになる前にとっとと首を引っ込めろ
そこだけでも何とかしようとソースを眺めてるんだが
w32term.c の5277行目の WM_IME_STARTCOMPOSITION のポストの意味がわからん
反映させようとしてるんじゃないかな
金賞もらいました。
ttps://cygwin.com/ml/cygwin/2014-10/msg00495.html ttp://cygwin.com/goldstars/ emacs-devel じゃなくて help-emacs-windows だけど gnupack のを投げた人は
いたみたいね
ttp://lists.gnu.org/archive/html/help-emacs-windows/2012-04/msg00006.html パッチを添付してるように見えないけど…結局パッチの出所をはっきりさせて
法的文書にサインしろと言ってるな
正確にはIMEパッチはMeadowの人が書いたのが殆どだから、法的文書にサイン出来ないだろうね
いや全て俺が書いたって言う人がいればいいけど、それよりもコミッターを説得するのが
最大の難関だと思われる
そうすりゃ誰もが満足するだろ
あ、パッチそのものは投げられてないですね。すみません。
256さんの言ってることには完全に同意。現状のIMEパッチが公式に含まれる
ことはまずあり得ないと私も思います。
DDSKKはインストールが面倒で設定も使い難い昔のデフォのままだしでかなり損してる
setqを20個ほど書けば使い易くなるんだがなw
単漢字変換みたいなもんだとすれば何らかのelispの追加で事足りてると思われる
64bit対応になっていたらそれで充分満足だよ
今ではあまり意味無いけどな
公式ビルドでそういうの出て欲しいのは確かだが
野良ビルドで十分じゃないの？
だけど、fakecygptyとか使っている人はやりたいことができてるんだろうか？
出来てる。以前と変わらず。
プロセスのパラメータがcp932なのも一緒のよう。
公式ビルドをリリースしろと言う人がいるってことは、いるんだよね？
「TSF対応の公式ビルドをリリースしろ」と要望でているんだろうが
TSF対応のソースコードがないのにビルドを出せってむちゃくちゃだな。
まあ何がむちゃくちゃなのかわからないんだろうが。
↓のをつかってるんですが
ttps://github.com/chuntaro/NTEmacs64 起動した際に
*GNU Emacs*
バッファのロゴあり版が表示されません。
コンソールで起動した時と同様の画面がでます。
about-emacsを実行するとちゃんとロゴ画像ありの画面が表示されます。
inhibit-startup-screenはnilのままです。
emacs用の一切の設定ファイルinit.el .emacs.d emacs.elなどhomeのユーザーディレクトリを空にして起動しても
コンソール版*GNU Emacs*バッファ表示しかされません。
問題は家のＰＣだと同一条件でちゃんと表示され、会社のＰＣだと表示されないという事です。
環境はwin7-64bit cygwin-x64です。
NTEmacs64は cygwinのbashから起動をテスト
エクスプローラーから直接クリックして実行（この場合設定ファイルは皆無）
上記のどれを実行しても同じ症状で困っています。
設定ファイルに依存していない場合環境変数などですかね・・・。
.bashrcなどもないのでWindows環境変数を受け継いで、それらが家と会社で異なるといぐらいしか想像ができないのですが・・
アドバイスお願いします。
24.3-32bit版(GNUPACK)は↑の問題はでていませんでした。
あともう１件あるのですが、
起動時にpackageのインストールとバイトコンパイルをした場合、
24.3まではミニバッファにアクセスアドレスやコンパイル状況が表示されていたのですが
24.4になってから何にも表示されなくなり一見長時間固まっているように見えて困っています。
これらを表示する方法はありますか？
TSF対応のソースコードがないのだからTSF対応のソースコードを作ってビルドを出せってむちゃくちゃだな。
まあ何がむちゃくちゃなのかわからないんだろうが。
起動時にロゴが出るか否かはフォント(関連dpiとか？)の設定で決まる
詳細な事は分かってないけど、ちゃんと設定出来てないとなぜか表示されない
これはLinux版でも同じ
(setq initial-frame-alist ((font . "MS Gothic-9")))
みたいにとりあえずフォントを設定してみればその内表示されるはず
これは全く原因は分からんな…
1つあるとしたら、NTEmacs64は64bitで最適化ビルドされてて実行速度が速くなってるから
Windows側の再描画が追いつかないだけなのかもしれない
もう1つ原因があった
PATHのどこかにlibpng*.dllがあるのかもしれない
でそれを使おうとして(32bit版だったりすと)失敗して画像が表示出来ない状態かもしれない
表示されない方でpngとかxpmの画像が表示出来るか確認してみると分かる
表示出来ない場合はPATHをいじくるかdllを削除するとかの対処が必要になる
splashが出たり出なかったりする。
ほー、そんな事あるんだ
実用上の問題は無いはずだけど気になるな
アドバイスありがとうございます。
今日フォント以外を調べましたがどれにも該当しませんでした。
まずxpm,pngファイルの表示ですが両方とも普通にできております。
dllについてはlibpng16-16.dll, libXpm-noX4.dllはemacs.exeのカレントディレクトリに存在しており
ttp://msdn.microsoft.com/ja-jp/library/7d83bc18.aspx ↑のdllロードルールに従うならカレントが最優先なので他に存在していても最初に読まれるはずです。
ちなみにcygwin上からNTEmacs起動時にGnuWin32へ一部パスがとおっていたのでlibpngは他に存在していましたが
エクスプローラーから直接起動の場合環境変数にGnuwin32は入っておらず、他にpng,xpmのdllは存在していないにも関わらず同様の症状です。
アレからいろいろ調べた結果以下のことがわかりました。
*GNU Emacs*バッファが作られる際にX-Windowかコンソールかを判断してコンソールなら簡易版
X-Windowなら画像付版を表示するようです。
それを行う関数が
(defun display-startup-screen (&optional concise)
であり、この内部で
(if (use-fancy-splash-screens-p)
(fancy-startup-screen concise)
(normal-splash-screen t concise))))
となっていてX-Windowかコンソールかを判断して呼び分けています。
ですのでこの関数の結果がnilになってコンソール版が呼び出されていました。
さらに挙動を追いかけていくと
(defun fancy-splash-frame ()とその内部で呼ばれている
frame-visible-pの挙動が原因であることが分かりました。
(defun fancy-splash-frame ()
"Return the frame to use for the fancy splash screen.
Returning non-nil does not mean we should necessarily
use the fancy splash screen, but if we do use it,
we put it on this frame."
(message "fancy-splash-frame : 0")
(let (chosen-frame)
;; MS-Windows needs this to have a chance to make the initial
;; frame visible.
(when (eq (window-system) 'w32)
(message "fancy-splash-frame : 1")
(sit-for 0 t))
(dolist (frame (append (frame-list) (list (selected-frame))))
(print frame)
(print (frame-visible-p frame))
(print (frame-selected-window frame))
(print (window-minibuffer-p (frame-selected-window frame)))
(when (and (frame-visible-p frame)
(not (window-minibuffer-p (frame-selected-window frame))))
(message "fancy-splash-frame : 2")
(setq chosen-frame frame)))
chosen-frame))
コレを実行すると
fancy-splash-frame : 1
までいき２まで到達しません。
原因は(frame-visible-p frame)がnilを返すためです。
emacs起動後にscratchで再度この関数を実行すると２まで到達します。
ソース内コメントで
MS-Windows needs this to have a chance to make the initial frame visible.
とありますが、どのようにしてvisibleになるチャンスを得るのかもわかりません。
そして、この関数は自宅で試すと起動中、起動後もｔを返すので正常に画像あり*GNU Emacs*が表示されます・・・。
また、frame-visible-pは
frame-visible-p is a built-in function in `C source code'.
だったのでこれ以上終えませんでした。
これ以上やるには、24.3と24.4のソースを持ってきて調べるしかないですが泥沼になりそう・・・。
それと
>1つあるとしたら、NTEmacs64は64bitで最適化ビルドされてて実行速度が速くなってるから
>Windows側の再描画が追いつかないだけなのかもしれない
スペックは
家、CPU:core i7 3770K GPU:gtx680 memory:32GB
会社、CPU:Xeon E5-1620 GPU:gtx770 memory:32GB
と似たようなものなので大差があるとも思えないし・・・
うーん、どうしたものですかね・・
> うちは同一PCで同一バイナリを同じショートカットから起動しても
> splashが出たり出なかったりする。
それは24.4-x64だけですか？
24.3からありました？
おお！詳細な説明ありがとうございます
だとすると完全にタイミング依存のバグなんだろうね
フォントの設定を変えてうまく行ったのは、何らかのタイミングが変わるからだ
ちなみに、これは24.3にも確実にあるバグ
なにしろ自分が24.3を使ってる時そうだったからw
実用上の問題は無かったから気にはなってたけどスルーしてた…
それとログが表示されない件は再現出来る手順を教えてもらえたら
自分のPCで確認してみたい
(frame-list)に(selected-frame)を足してるのもタイミング調整くさいし
(sit-for 0 t)のtはnilの間違いでしたっていうstartup.elのミスじゃね
>それとログが表示されない件は再現出来る手順を教えてもらえたら
>自分のPCで確認してみたい
じゃあちょっとお願いします。
miniバッファにコンパイル過程が表示されないだけで*Compile-Log*バッファは存在しておりコンパイル結果も残っています。
症状の詳細を説明しておくと
24.3までは起動時にパッケージチェック＞ないパッケージをダウンロード＆コンパイルという流れが毎回走って
*Compile-Log*そのもか、その過程がminibufferの位置に表示されていました。
このときテーマ設定など一切の設定は行っていないのでメインフレーム部分は真っ白ですがモードラインは表示されています。
しかし、24.4からはメインフレームは白なのはかわらないですがモードラインの表示もなくminibufferへも*Compile-Log*の内容も流れず
一見するとフリーズしているかのように見えますが、裏ではしっかり動いています。
でもこれだと本当に通信などでフリーズしているのか動作中なのか非常にわかりずらくて困ります。
この症状は家・会社関係なく24.4で１００％発生しています。
コードは次にかいておきますね
(add-to-list 'package-archives '("melpa" . "
ttp://melpa.milkbox.net/packages/")) (setq package-check-signature nil)
(package-initialize)
(defun my-package-install (packages)
(let (targets)
(cl-dolist (name packages)
(unless (package-installed-p name)
(message "Package: %s : not installed. " name)
(add-to-list 'targets name t)))
(when targets
(package-refresh-contents)
(cl-dolist (name targets)
(package-install name)))))
(defconst my-package-list '(
cygwin-mount ;melpa
auto-complete ;melpa
fuzzy ;melpa
helm ;melpa)
(my-package-install my-package-list)
とするだけです。
一番最初で行っているのは自分の環境設定などでload-pathなどが汚される前にコンパイルしないと
パッケージによっては想定しないパスをみてコンパイルエラーになることがあるのでコレを回避するためです。
表示が間に合わなくて省略されてるだけな気がする
ちゃんと自分の環境に合わせた最適化してる?
> ビルドオプションが悪くて表示が遅いだけなんじゃないか?
> 表示が間に合わなくて省略されてるだけな気がする
> ちゃんと自分の環境に合わせた最適化してる?
えっと具体的にはどういうことでしょうか？
NTEmacs自体をビルドする際のconfigureオプションっていうとでしょうか？
それともemacs上でのバイトコンパイル系変数の話？
起動直後なので一切のバイトコンパイル関連の変数は初期値のままです。
byte-compile-verboseとかはtになってます。
関連する変数の初期値が24.3>24.4で変更されたのであればビルド前に設定する必要があるかもしれませんね。
どの変数だかさっぱりわかりませんが・・・
configureに関しては自前ビルドではないので
ttps://github.com/chuntaro/NTEmacs64 の下のほうに書かれているものになります。
一応こっちでもためしてみたんですが
ttp://emacsbinw64.sourceforge.net/ かわらなかったですね。
多分svgで表示するようになってからのような気がするが、
trunkの自前ビルドなのでいつからなのかよく分からない。
ttp://www49.atwiki.jp/ntemacs/pages/47.html ttp://www49.atwiki.jp/ntemacs/pages/48.html mozcのoverlayモードは遅くて使えませんが、echo-areaモードは十分に使えます。
お試しください。
以前、mozc_emacs_helper.exe含めてビルドしたこともあったけど、起動はすれど結局動かなかったな
テスト用のS式でもあれば別だったんだが
64bitゲストOSを立ち上げるほどのことでもないので、32bitOSを立ち上げるように
手順を変更しました。
IMEが起動しないようにする設定方法ってありますか?
gnupackのconfig.iniで設定した環境変数の設定をntemacsに簡単に反映できることから長期間使ってきました
emacs24.4のものはまだリリースされていないようです
そこでgnupackのemacsに準拠するようemacs24.4を導入したいのですが何か方法はありますか
autohotkeyで設定すると楽ですよ
autohotkeyをインストールしてemacsがフォアグラウンドにあるときだけキーフックをすることになります
これをコピペして使って見て下さい
#IfWinActive, ahk_class Emacs
;;
ttp://ahkwiki.net/KeyList ;; 漢字
vkF3sc029::
vkF4sc029::
;; 変換
vk1Csc079::
;; CapsLock
vkF0sc03A::
return
やったことないけど gnupack の emacs 部分をそっくり差し替えではだめなんだろか
環境変数と追加フォントのシステム登録するラッパープログラムが追加されてるだけで
emacs 本体はパッチ追加して普通にコンパイルされてるだけだよね？
環境変数は (setenv ”PATH” ~) で変更化。
もし、emacs から外部の実行ファイルを使いたいなら、さらに exec-path という変数を弄れば可能。
それともホームの場所の設定かな？
もしホームディレクトリの設定で迷っているのなら、site-lisp 下に site-start.el なるファイルを作って (おそらく名前はなんでもいいだろうけど)
(setenv ”HOME” ”ホームにしたいディレクトリのパス”)
を設定すればそれが最優先される。
もっと具体的にやりたいことがわかれば、多分対応できるよ。
そうすりゃ gnupack のと完全おさらばなんだが
遅くなったけど試してみた
NTEmacs64を使ってるけどをやってパッケージが一切無い状態で
ミニバッファにコンパイル結果のログがダーと表示はされた
ただし最初のパッケージを取得してくる所では再描画は起こらずに白い状態だった
ブロッキングしてパッケージを取得してるようなので、そりゃそうだろうなとは思う
俺のPCはと似てて、CPU core i7 4770 GPU GTX760 メモリ8GB だ
(ちなみにの32GBってスゲーな…ゲーム開発でもしてんのかね)
Emacs24.3でのIME入力を修正する方法がgoogleフォーラムに投稿されていました
WIndows8.1 GNU-Emacs24.3で入力中の文字が表示されません。 - Google プロダクト フォーラム
ttps://productforums.google.com/d/msg/ime-ja/tgXztpe84ok/KPzOMmdhn8QJ >修正方法はそれほど複雑ではなく、以下の WM_IME_STARTCOMPOSITION ハンドラ内部で break; するのではなく、goto dflt; すれば完了です。
これをEmacs24.4で行おうと思って
ttp://ftp.gnu.org/gnu/emacs/emacs-24.4.tar.xzを展開してソースをgoto dflt;に書き換えてもだめでした IMEパッチが出ていないところですが、なんとかしてIME入力を正常にする方法はありませんか
ttp://ftp.gnu.org/gnu/emacs/emacs-24.4.tar.xzを展開してソースをgoto dflt;に書き換えてもだめでした いや、それで入力出来るようになるよ(試した事あるし)
ただ、それだけでIMEパッチと同等にはならんがな
そのパッチはgnupack由来のと似てるけど、IMEと直接関係無い変更が大量に含まれてるのがなぁ…
gnupackのよりはだいぶマシだけど
ttp://hp.vector.co.jp/authors/VA050396/tech_01.html で公開してくれてる TSFTest.exe を使えるようになればいいのに
さらに欲をいえば TSFTest.exe が機能強化して
文字列の部分変換と UTF-8 出力できるようになればいいのに
きっと変換精度が上がって、候補が?に化けたりしなくなる
もちろん一番いいのは Emacs の TSF パッチができることだけど
お！これはずばりそのものだね
IMM32みたいにwin32のイベントにべったり依存してない感じだな(良く知らんけど)
これならTSFTest.exeを改良してkkc.elから呼ぶのも全然可能だろうね
出来たとするとw [半角/全角]→quail(kkc.el)起動、とquailがMS-IMEと
キーバインドに互換性が無いのを修正すれば、めでたく完成だな
ありがとうございます。
パッチを当ててバイナリを生成してみましたが
残念なことにgnupackのサイトで配布されているNTEmacs24.2とはやはり挙動が違うままでした
#ifdef OS_WIN と書いているのでできそうな気がするけど、VC++がない。
ttps://code.google.com/p/mozc/source/browse/trunk/src/unix/emacs/mozc_emacs_helper.cc コンパイルできてGoogle日本語入力のengineと連携できたりすると、
最高なんだけどなぁ。
twitter検索したらMacでは出来てることが分かった
kkcに使わせるのは簡単だったけど一文節ずつ確定するのがめんどくさい
なので複数の文節をまとめて変換して一気に確定できるようにした
学習機能は削ったけど思った以上に快適
githubにうpするんだ！
TSFTest.exeのLinux版(もちろんiBusにアクセスするやつだが)を作れば
マルチプラットフォーム対応も行けそうだな
ttps://github.com/chuntaro/NTEmacs64 これの通りにビルドしてみたが、pop.cのビルドでgetaddrinfoなど知らんetcと言われてビルド失敗する。
socket.hまわりの設定が何かしら間違ってると思うんだが、ビルド条件色々変えたりMSYS2再インスコしても変わらんので
誰か知恵を貸してくれると嬉しい。
使ったことないから後はまかせた
xz -c < kkc-cmd.el | openssl enc -e -a > out
でxz+base64にしてここに張ればいいかな
そうか…残念だ
とりあえずbase64でも何でもいいんでアップしてくれ試してみる
ちゃんとソースは最新か？ →
ttp://ftp.gnu.org/gnu/emacs/emacs-24.4.tar.xz とりあえずビルドを通したかったら ./configure --without-pop とすればいける
movemail.exeでPOP3が使えなくなるが絶対使わないと思うから無問題
つなげてoutに保存して
openssl enc -d -a < out | xz -dc > kkc-cmd.el で戻せるはず
使い方は
ttp://hp.vector.co.jp/authors/VA050396/tech_01.htmlの TsfReconv.zipをダウンロードしてTSFTest.exeをパスの通った場所において
kkc-cmd.elをロードするだけ
前半
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4BQ2BUJdABQciKdFOeuwuHqD57oYe+zL
h6yudf+Pjn9/8kQdS6GItEUvwJucOsQZ9o2wOEXJjVBqBhyb0C64o4sfhprBnCYS
20IGtw3bllD/nqUJu76y10srhTBwTPmTWGyJKlcAVvtGVi0xepOzfeBKvNq6z7Vu
q4Kl4d0nIBi2xWNtAXao6fNyTBwtxUBctRzt3BXEUHmpG8oCNcR2t5631p8mtSjA
A501NHOTMxO4ghWxbhxDXZP6qyLBHADznPSgjuJlw8FLKyTDbd69mtWJ+2bZUn2b
jTYby5mP0OKhmW7mU7VqBCWpfR2LO0wPs97ZEH6kECSDba8I8eKolAqT/rHsFUfC
4CEPFLaf0qP4AHGu1EONZK9Gl6P1E0qW8jbYAX9iuduWo8Bd4ari98UIyommjKM0
lC8iBRv+txBN7Q7BvYAQjw7Izr1OA8MrfrvE0LEUQNvsuxS9fsDxdgtl4CiATg0a
98MzCawKbmPtJyU73Sg3mj5K5RiWP4B9C6mYdJIQGHXVnDyQNR0bzGNwW74iXtWK
FrDQf8SMapRq6GBuDEQdDoHvXreFSNhPCIeBSw20BMKejfsSsPsc8n/ERk0A38nI
FTWjL3cjYU85qz0DEgU0GIqWB3NY9KScsU5YYluZBnq9Qr3NFi7Jcwmzv7bmuTX5
9f1iOkgnT9e7Dp08LN/qGuVI1tosIGA5xOS6y4GZ6F32ekjOUVi/fUredKefhNHL
laC15if0z5PjhgSxt5TuGcaAlr0F+7dBy0CPBCMIY2w4V2k/ayZVAEu2AKIPhyhy
tDR3tOtT7DKu+BwjhDjT5u8aljY2iIsLc3NRBaHviDhoRljX8Pv3mLGgBVUffcNH
RMQQumlWde9WANfTc9vt0wnqmCIWrR0uzyX4L7vUMKSOLPv8yeBZXYMe4WjaTo9J
xiuv9+kdxTUEsE7D9W3eu/oB0/C3db3C3Nq9Y6FwaOINQbco0DYmd44GvJBZfQ9E
orRz0n4pFYq4u/B/b9kClY0XJejFjE04JvSGqxHurlid7knAdo/eT6ydPhWxWq6O
kQW42XJtdgua2G4z5ViRvrsuCi0+Fv4fISyk/BjGDyDsou/pPNwLjnWi8ZGrHvyW
jfGSPhm/FSlZ3cO4+zQLr0QS3du1jsWfZW6oLzaHCRRUjxkxqpDrQcWerq3QgKRG
a1xJ4CHftVbiQctmQcGxXODh0fjd6rgqS5ubjR/l3O46OmnRiWxTEtopJ0xDake/
rtbe75YgLdkdOK0wEr5yak/kBOYiKBC26uiyKe1ut01uGcEqU0Vv8T9j87qi8mt8
qLcirApziyD/TZwgz5njKZJDMpwU5PMUu6VfaRhgdiGx0z7s30i0mVOhBPJzWDWh
RGGpBTkqvUUDnzslzUMDJrmu4wN2HbAzoUpey/l+83xlt/0SDFhFp36HDi59ljs+
d0hB+F/tbhfWGjgtKaRvKHHdeR0uyPa7kyW2BOlQm36ZgAfWGxemZNyoNOqYgSF+
8F8gEGxXZQ8A9dpzDliAKf8dyyMhReadf00NYlpoGknU2sG+oefxGlxmlHp3rLSK
0fbHqZH1H6MMpBYVV7DUyUZM8iPhscuiM6mMXBlS07+CW609iT0KdslNsbyRl8Ah
QWo0zv7z2jlmoH2am8uW0ZSccCr7CL/DAfnpCDM9vVAjPCdehZAJ0kk3iPS9UJNx
wxkcZTLdTbWRcfT6JanllP2nVcEgpiQPwlfPh+lrcG68ggyQK02yRmf8FKNUTv9/
52ClSj/dVA0XtitfmcOIBWTVeUd6FOL6slAhejHoN0XZAAAAi12Cgt/pKEcAAd4K
tygAAFjQKhexxGf7AgAAAAAEWVo=
エラーチェックも一切ないからあくまで確認用ってことで
msys2をpacmanでアップデートする
cygwinにパスが通っていたらディレクトリをリネームする
こんところをやればだいじょうぶだと思うけどね
自分もそういう現象になった
windows8.1とwindows7のPCを使っているんだが
windows7だけgetaddrinfoのエラーが出てwindows8.1の方はビルドできた
どちらもpacmanでアップデートした
だけどのいうパスは気にしていなかった
ビルドできたwindows8.1の方はcygwinに環境変数のパスが通っていない
そのあたりがポイントかも
とりあえず、えらーでへんかんできない。。
Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
=(nil 5)
(if (= len (length key)) (setq ret (list len "" conversions)) (let ((rest (kkc-run-lookup-command (substring key len)))) (setq ret (list len (concat (car (nth 2 rest)) (cadr rest)) conversions))))
なんでだろ
IMEの違いかなあ
(if (string-prefix-p entry key)
(setq len (length entry))))))
にかかる候補がうちだと必ず出てくるんだけどね
他の可能性はエンコーディングだろうなあ
というわけで残念でした
すまん、TSFTest.exeが動かないのはGoogle日本語入力を起動してたからだった…
あと、LANG=ja_JP.UTF-8になっててもTSFTest.exeが動かないな
つうことでこの文章はそれで書いてるよ
変換精度は高いのかもしれないけど、いかんせん使い辛いな…
これを解析してちゃんとしたものにしたくなってきた
とりあえず、アップしてくれてありがとう！
アドバイスありがとう。無事ビルドできた（--without-popなんで根本的解決じゃないけども）
確認してみた点としては、対象ソースは最新で、pacmanは更新済み。
cygwinについては、うちの環境はMSYS2だけ入れてcygwinは入れてないから、cygwinの混同じゃないとは思う。
でもconfigureのメッセージ確認したら、sys/socket.hもgetaddrinfoもyesになってたから、やっぱり何かおかしいな。
多分MSYS2の問題だろうからスレチだけどこの辺り確認してみる。
MSYS2環境でビルドする時、もしavast使ってるなら、少なくとも常駐保護のファイルシステムシールドは切った方がいいいと思った。
プログラムの実行のたんびに実行ファイルをロックしてチェックしやがるせいでPermission Deniedが連発した。
sys/socket.h は yes でよいと思う。nt/inc/sys/socket.h が使われるはず。
64bitマシンでの動作確認に手間取っているのだろうか？
やりかけだった文節長変更まわりを仕上げるついでに
エンコーディングについては対応してみた
LANG=ja_JP.UTF-8の環境でも使えるけど
IMEの違いによる問題はどうにもならんなあ
気づけば実験だったはずが普通に使ってる俺がいる…
遅いし、文脈見ないし、学習しないけど、なんか慣れたw
・・・既読メールが表示されないんだけど、どうすればすべてのメールがみれるのだろう。
そこら辺カスタマイズして普通っぽくする方法解説してるサイトがあった記憶があるから
頑張って検索してみてはいかがかと。
ありがとう。頑張って探してみる。
ちなみにメーラーはなにを使ってますか？
netnews 見ることの出来る環境だったころは wanderlust 使ってたけど
今はプライベートは完全に Gmail を web で直接だねえ。
Gnus も接続設定だけはしたけど web で見たほうが動作が軽快だったのと
HTML メール見るのに w3m わざわざ入れるのがだるかったのとで全然使ってない。
メーリングリストとかもう入ってないしそんなに頻繁にメールでやりとりしてないからってのもあるからなんだけど。
なるほど、確かに Gnus の動作は遅い・・・。
emacs でメールをみようというのは時代遅れなのですね。
参考になりました。ありがとうございます。
色々ウィンドウズのEmacsだけ文字の一部が書けて見苦しい
NTEmacsにも有効なフォントレンダリングよくするやつをMactype以外で紹介してくれないか?
MactypeはWindowsアップデートの際に事故る報告がちらほらとあるから恐い
まあ、あれは元になったGNU emacs(x64)の修正部分でとりあえず動いたものも
入れてるので…
確かにIMEに関係ない部分が多いのは気になってたので関係なさそうな部分を
ざっと削除してみました。削除忘れとか削除しすぎとかあるかもしれません。
前のはemacs-24.4-x64.diff にリネーム。
Thank you
調べてそのあたりを試してみるわ
ttps://github.com/chuntaro/NTEmacs64 に IME-patched ビルドを追加したよ
見たところ本当に最小限になってたんで早速そのパッチを使わせてもらいました！
ありがとうございます！
何かライセンス的な事とかまずい点があったら教えてください
(もはやIMEパッチは色んな人の手が入ってると思うけど…)
おかげでうまくいった。ありがとう
ttp://s1.gazo.cc/up/107320.jpg 胸の鼓動を抑えきれず、早速x64 Win7ノートに入れた
10分程度使ってみたところ、快適そのもの、so far so good
明日x86 Win7デスクトップにも入れ、しばらくこれで生活してみて、レポ差し上げる。
たくさんありがとー（many thanks）
ttp://lists.gnu.org/archive/html/emacs-devel/2014-11/msg00478.html (emacs-version)が、25.0.50.1と出る。
/Td6WFoAAATm1rRGAgAhARYAAAB0L+Wj4Cp0Cg1dAB3gfNeGMWmRxKAU6n/NyHYh
6mcYJhX3ldyH6MgkcRL8dCy4tSNheFUf914/t89QwVC1gmWCPq440SWAslOnsfA/
/R93nSbpHY4bLEpBkwADQ631LFiOv1cKKHl4NvRhn7d13U0oQjc7zqqlhlrPVnet
17FzMGiAkU1q+j7ZdMCFzAMW/U3vOGBuWbSVEi1hnvYboSWNqq5Zwb/P3u9bQUNp
b3Dy5B3celMZpUkwsy6KIOrx1xVv4DaiaRKRmSCAsexg8/EKIpqbX0YF5iBP8mmd
PQFTeHCxDwmm5s/X2ufY5CLMtse2bqiBPyFwabKgYbUJSerX5dR3Ibp5lsIdpUS/
PDQEvp+5lctinalC082gc+YA6AeJA1lZ3o13Ck4yyrprrl06PVykzSm+S9HN+7+i
t82xra+L2IQFYTVWgppnvUInKv7YnFYa+k2E5+dP5msidTYHi35wH+IbKjNhLA34
kJCgthN9Pi3pwYo4AjDIKeOAXwuEnZmAk0KiX+EjhwALKcEGuoigU9yDkDn2Ycpl
Y395aNBZrQYntYJu/cULGfztgEppgzq2fT/kO+LsWNVA9Laj2OwHTYuMu6IxSr8m
aGMAlYx7y+QLRqo/K0tH6Gow5d8hpI3cpvYhOKB2b2Az+dnMoorxS13mPDnjVHoz
PkD9/hG+Tu7FIK41ukmv2pC/mqqhCbAR/ORrh8C0akxLKXAJcZ/XfyUhExydJ2ef
U9hLNsJiJl0YeDatnWWL2QQrMnNriW7FG1YN7hi//LcRwVDS0aKTcYKSoA8UlkBF
vdflG9JEA86IaRX2qt9YLSpDvbIf1+mnSRfZV1Zz+xtpMX8jVdCmjSwn1p854g60
vNDM+PDtMqJcasZx9hQDqhihotICbx0J75XCzQ4+kookpUca7e6Ozipf9IF07x6S
h0TCHkhI8sxNVBovtUbY+GWn74pNYH9itSJ5rPQZGPESSQkZrF5Aaom3mHRFrYgc
nNSaCYj6L3JsYneICYVEFbTwvW1O6eo0Q2MlIAuc5h6E28GYe2kN1mK7dAKJChsb
g7ru3WjD4RcckvOlmLCzVv6HuCYV1WKS5dfJesT0wBBXMqExOUJ6f39c9kCxqW1L
FsJykCkt1YZTegSpFsw8S5xYIXZDdYKW4HBDnahfoCYqz3meL1vizgkDasWJVCtF
4gsAvEck+pxSiteX7wUvJTSj4SydXU5wUsu+BJ5XZi//LiQlPMImhVvL56yzCQlA
/XP6mZg7P0SKtBk0ACc7S51d0sSvPfjnDkLh8j+DRqU1gOqoZDKRrckSQODBBy63
P8K8RgLLT8DoNNXtT00jrnP7HrFZzXTS3zYFZngRwfM1ZIdlPVNRxifUFApQypBF
0b6YBy2OWYX1JB7caGsI2yTAWDcY1KpYGXyhgn0vligGS+WSSISOH0n/y4nNmrRY
Fn5EcMXTk0GSL5kv8iHxbUiHC3uKYZGXDoVVPpWd193vLtzUZS85mhLxynR4L18N
sRP5LymhIodY2cnNGyYzxEoZGgFkDGo3FxxWB8gn4BtMrBRdTfwoKgJWSNtFn4x7
PZaD/ssRxGFlWfJMOhTUsGXH2ot/6D4uA8ozpug8gQnRY+SA9funi+8Q3M+w/L59
XRemfsovLs21G7hlxGVJUBi6byR9v1Q0cLQvODG0xrYmguQZjcb94smBGZsey7m2
jzLV4FtSpihY+Sg4AX72w/7DXSTW3gKcFPPM/gUkfs3iS+rFfoWQMjiSUxiAyqh6
2sPHowDz3WMI2hmcwma34njPCEIGfxIht+pzkZ4LE5xmWRJkoNjQAQtmU94Ha1u6
vbc4yrT5NdSM4r4Or4pJopkk+FfEfWuZnT+6Qgwdez2TcQus0FGrcr7nTQAWzSM7
OG9bA9EYZKabuBth05ZFlruO8uxmkw8vUlTRZJrtptKhD7fSvO5a3C5f2MifM/KJ
3G60RrTkPC8YDiDWUGteDrHb8q+cAJ62oKNJI1FF9Svvg0xq9gHq1qGNgX15YO3y
1AVAE9qE6sFHoWyIGGV1gHiS8z1RjS9pNI/VzFbsOfInE36ysa7B9tPB4qs0SCOI
EUJ4FEnqb0BCaABHjs+O3uq0NwLbDuzKHPQ6tO62Vr/Uv/cku05n/komM2WIybRe
c2CbC2hqNVefnKqAVYiFH6V9AiVThKP+jv6XM1Tlm8SHXLr8uqPA4AxayEzJ4Iki
ISaSdFQxO01Ex4DosHjl2GWuNLSm6ih5BVCQVmTDzAlJIZOpSD7Bk+t6Y3+ea3H/
USJ/cJDKkhDTS/xCtWBDo3yXLBvFMP4JNkvH5G9J9ErPq3nOLV+cWhtUcBp0c8Ok
qGQvb3NBJRm3OnvXPD3A1UcoQr5MWXXvA0O1T1+m+wqCMkO9aBTLIkxddLq/urHg
sWDzDmtSaALR0xuLZBJfUScd8JA3HkLbPgM+Dqkyqu8bLakzw7ADeI899jNaNsTn
Zf+FVPrGTCwvIZ5QOUuFG5dMOICKREB4nKaJ/X571DU5Hbl4jiPpXrI7SBZpqYSq
3y5WAgRWnbTEiY+Qfq2lcrUCJNDW59OG/BrqxadF3G8nrQybs/SkbxqQXIp3KDfI
dhQSic7gkyTRYmPj1zKPDICuJU0tApfbKmjIJMNB7qrcVCWD+Qk4PICIPOQNPMKP
6ObTz8wgrYcEdvy2m1lbXB1hTJtTF1jIOYjmACQAmymVNLPxVN+3tmDUVNrB6kt6
CJKapz8Q/692gN4o1paMT62IqUN8n2Uml5zWdumZ6KaiL3tdGbdgEUEgl+7NE7Zo
/xA6NmwlRwAvQvwWcfwai6XQ3+EBgerjmeiKUCW4Ijv4xX9gdPqfhPY46RUp9NiX
wDO2nH+1cBHvyZGzN+lIosZS13+KPMiQgW85vmkzjy/ReM3rzUZOv/IdVFpiqNnr
HHZDeK2PrHX/7zIRT3GUxa5kfc1vYu3HGdNvHKcZdSuTEjQRwukuiSntlRNka2JU
fpmcqNzejBhlkrgvy1FhuUWS566ClYQ6ro7lvf7z9G7vPoE71MMh4k0JcLEf3XPW
hAdQYqFqO4wmy2o4R38oOnOpfso2BKwCbKB/RYzSQI+3CqvfjM2kxXtnonFWnMP2
lL/db3NLBXejjbdoAGd6kwhX6G3/i9nkaGN7tDePu1dsbqXAScF9rTH+kxat5Yp3
OCpbUWVFhMzSVRod8Unj8uKAj4Qqax1U73cWLxe0MY5XRNvT9q9lkbTr1X9ybhz3
ABSDPvMtB59jhLzyjawnDukdbDD7fHBAhorwCiAq3568wMGAslZNf7I7CKF6fsvW
I/OdLS9Fo2TEyTBCfl7EkUMOGJH1rHx2irvCLv7JPqs1CRjQiIvbz70Qn6m9MUeO
TYev/lTdgQBlX5ESF/iOLS9xgwX/hEyG+973rKiDwZZf71WfWoIFGKEku8CkZvyb
btvgwIsN97m7FdJmAAAAAEh2bJajO5Z/AAGpFPVUAABAxSuyscRn+wIAAAAABFla
いやいや、こっちが本命w
TSF使ってるしマルチプラットホーム対応が出来る可能性もあるからね
ただgithubなりにアップしてもらいたけど…
スレッドモードで / o だ
それとGnusそんなに重くないぞ
それにewwの元になってる内臓HTMLレンダラがあるからw3m入れずとも表示は出来る
(見た目は酷いもんだが…w3mとどっちがマシかな)
Gnus使ってるから分からんことあったら聞いてくれ
おぉ、ほんとだ！表示された！！
ありがとうございます。
あまり情報クレクレするのは申し訳ないんだけど、お言葉に甘えてひとつだけ、
~/Mail/archive
に情報が残るのが嫌です。
メールをローカルに保存しないような設定を教えていただけませんか？
すみません、自己解決しました。
win8.1 なんだけど起動できない…
Emacs Abort Dialog に
A fatal error has occurred! らしい
runemacs.exeを実行して起動が出来る事を確認しました
ビルド済みの物、ありがとうございます
そこで質問なのですが設定ファイルはどこに設置すればいいのでしょうか？
初めてのEmacsでなにもわからず…
どなたかご教示頂けたらよろしくお願いします
ポータブル化したいので、この設定の場所を起動オプションで指定出来ないものでしょうか？
とりあえず、.emacs.d の場所は、
のように、site-start.el で
(setenv ”HOME” ”パス名”)
とすれば、そのパス名以下に .emacs.d を置けるよ。
ありがとう！
何と！Windows7では問題がないけど…
考えられるのはPATH上に同名のバージョン違いのDLLが有ること位だ
それか単にWindows8.1と互換性が無いのか…
それかも
AMD の phenom x4 なので
うーん…corei5では問題無く動いてるし、64bitビットCPUってそんなに
バリエーションが無いから問題無いような気もしてたけど…
Win8.1 AMD FX-9590 →起動可
Win7 AMD PhenomII X4 905e →起動不可
でした
-marchは何にすれば最適なのかね
環境変数 HOME を設定すれば、$HOME/.emacs.d/init.el を見てくれます。
ただ、runemacs.exe をタスクバーにピン止めして、それをクリックして起動すると、
もうひとつアイコンがタスクバーに表示されてしまう。
gnupack だと1個のアイコンで済んでいたような気が。
（何か細工していたのかもしれないが忘れてしまった。）
うーん、よくわからんですが-mtuneでABIと命令セット以外は最適化するみた
いだから-marchなしでもよい気も。あえて指定するならcore2とかかなぁ…
ttps://gcc.gnu.org/onlinedocs/gcc/i386-and-x86-64-Options.html -Ofast -march=x86-64 -mtune=corei7
でビルドすればいいのかな…
半日使ってみましたが、全く問題なしです。感謝感激です！
おお、x86-64ってあるんですね。Win8.1 FX9590 でビルドして試してみたら
-Ofast -march=corei7 -mtune=corei7 →PhenomII X4 起動不可
-Ofast -march=x86-64 -mtune=corei7 →PhenomII X4 起動可
でした
速度的にはどんな感じ？そんなに変化無いとは思うけど
ごめん、起動できるかどうかしか確認してないので速度的にどうかはよくわかりません
普段は自ビルドしたもの(特に指定してないので最適化は-O2のみのはず)を使ってて
今試しに
のもの使ってnavi2chでこれ書いてるけどあまり変化無い感じです
試してもらってどうもです
IDが変わったけどと同じです
> 明日x86 Win7デスクトップにも入れ、
うれしさのあまり、chuntaro/NTEmacs64ってx64用なのを忘れていた
x86 Win7上では当然のごとく、怒られて、これでおしまい
PhenomII X4で起動できました。
しばらく使ってみてました
で自ビルドの-O2とあまり変化無いと書きましたがそういうつもりで見てると
少し早く感じますね。generic-cpuとそうでないのとではそれほど変わらんかな
最適化しました！が前面に押し出されてるので私が期待しすぎて最初はあまり変化無く
感じたのかもｗ
手ぬるいツッコミありがとう
むしろ何かの拍子でx86用ビルドだと思い込んで、x86・x64マシンの両方で使えると無駄に喜んでた
EmacsはCで書かれててinline指定とかしてないから、普通にコンパイルするとインライン展開されないはず
で、-O3以上にすると小さい関数を勝手にインライン展開するから、それで速くなるんじゃないかと
思ってはいるんだけど、実際だいぶ速いような気がする…プラシーボ効果かもしれないけどｗ
実際結構うれしいもんだと思うよ
24.4 で気付いたところは
(org-remember-insinuate) がなくなったのと
(require 'eldoc-extension) が壊れてそうなところ
あれー いま落としてきてやってみると
(emacs-version)^jで
"GNU Emacs 24.4.1 (i686-pc-mingw32)
of 2014-10-25 on LEG570"
起動時のスプラッシュ画面でも
This is GNU Emacs 24.4.1 (i686-pc-mingw32)
of 2014-10-25 on LEG570
と出るよ
ダウンロードするのが違っていた。
すまん。
64bitの対応にそんなに手間取るのか？
24.3 ですでに直ってたんだなこれ
ttp://cha.la.coocan.jp/doc/NTEmacs.html 情報ありがと
単漢字はまだしも、単語入力は俺には難しくて、使えんかった
ちゃんと日本人がレポート出したから直ったんだよ。
392みたいのが何回書き込みしても何の役にも立たない。
ユニコードAPI呼び出すようにしてくれってのもきちんと要望だせば
受け付けてもらえる可能性もあるのか
ttp://rubikitch.com/2014/11/11/ntemacs64/ SKKとか今どうなってるんだろ 使えなくなったとか
3日も前の記事を出されても…
SKKは今も使えるよ
magit-statusの所で失敗する
具体的には
パスの先頭に
c:/cygdrive/
がつくのが原因。だが、それをどうすれば直せるのかわからない
find-file や dired の方は問題無く動くのだがmagitの方は駄目だった
c:/Users/foobar/Desktop/testMagit => c:/cygwin/c/Users/foobar/Desktop/testMagit
cygwin-mount は入れてある？
今その cygwin-mount.el 入れてきた
(require 'cygwin-mount)
(cygwin-mount-activate)
ただし、eshellの上からこの2つが通らないからcygwin-mountの設定を詳しく探ればいいのかな?
cd /cygdrive/c/Users/foobar/Desktop
cd "/cygdrive/c/Users/foobar/Desktop"
Emacsが出すエラーは "c:/cygwin/c/Users/foobar/Desktop/testMagit isn't an existing directory"
これに対してcygwinがpwdで出すパスは "/cygdrive/c/Users/Lord Creator/Desktop" で"c:/"が無い
ありがとう
ttp://stackoverflow.com/questions/3286723/emacs-cygwin-setup-under-windows このURLの設定(cygwin-mountの為の設定)追加でmagitが動くようになった
git が cygwin 版のじゃないとかかねえ？
ともあれ助言で助かりました
野良ビルドじゃないか
ttp://developers.slashdot.jp/story/14/11/14/0428257/ オープンソースに公式も非公式もないだろうに
公式ビルドにこだわってたら有用なelispすら使えないよ
◆同じ www.gnu.org/software/emacs/ からの「nearby GNU mirror」や「GNU mirrors」にはないが
「main GNU ftp」の ftp.gnu.org/gnu/emacs/windows/ や ftp.gnu.org/pub/gnu/emacs/windows/ には
emacs-24.4-bin-i686-pc-mingw32.zip が上がってる
◆15-Nov-2014 06:29付けアップのemacs-24.4-bin-i686-pc-mingw32.zip中身は
GNU Emacs 24.4.1 (i686-pc-mingw32) of 2014-10-25
誰か解説してくれるとよく眠れるようになる
あしたやってみよう。
32bit用のものだな。
64bit用はさらに後なのか？
全部
ttp://ftp.gnu.org/pub/gnu/emacs/windows/ に設定の仕方書いてあるんだね。
君のは何bitマシン？
したい。
64 bit マシンですよ。
問題なく動きました。
今回の公式ビルドはポータブル用途に使おうと思っているので、32 bit でむしろありがたかった。
連文節変換があてにならんってところから始まったプロジェクトなだけあって
そこら辺はいまいちだしね。
してあれば、mozc_emacs_helperを追加するだけでmozc.elが使えます。
あとでmozc_emacs_helperの作り方まとめてみます。
mozc.el → mozc_emacs_helper.exe → Google日本語入力
ibus.el → ibus-el-agent → IBus
この辺そろそろ統一する猛者は現れないもんかね…
TSFTest を引数かなんかで IMM32 使うように切り替え出来るようにすれば
GoogleIME でも動くようになると思うよ。労力に見合ってない気もするけど。
試してないけど Windows8 なら GoogleIME も TSF 使うらしいから TSFTest そのまま動くかもしれんね。
ttp://www49.atwiki.jp/ntemacs/pages/50.html 内容にちょっと自信がないので、試してみる方がおればその結果を報告して
もらえるとうれしい。
バイナリキボンヌ
今、試してるんだけど
Visual Studio Community 2013のDVDイメージが7Gくらいあるのな
まだしばらくかかりそう
でも結構時間が掛かったが。
ttp://opensource.org/licenses/BSD-3-Clause Redistributions in binary form must reproduce the above copyright notice,
this list of conditions and the following disclaimer in the documentation
and/or other materials provided with the distribution.
それは元がオープンソースのソフトをバイナリで配布する時に守るべきライセンスなんじゃないのか？
ん？ 今したいことがそういうことでは？
ttp://www49.atwiki.jp/ntemacs/pages/50.html LICENSEを同梱しましたが、問題あれば指摘ください。その際は削除します。
とりあえず、大体書いてある通りでできた
Cygwin64を使ったんだけど、ソースのダウンロードでsvnがないと怒られたので
gitに加えてsubversionもインストールした
これで日本語入力が快適になると思う、ありがとう
確認ありがとう。
subversionは元々インストールしてあったので気づきませんでした。
wikiに追記しておきます。
バイナリで試してみた
普段Ubuntuでmozc.el使ってる
同じような設定でwinでもすぐ使えるようになるのがすごくありがたい
大きなファイルでカーソルがもたつくのはチト辛い
インストール時に何も特別な作業は必要ないのでしょうか？
すみません、公式ビルドをインストールする場合特別な作業が必用であれば
ここを読んどけというようなサイト等ご教示お願いいたします。
ttp://www.math.s.chiba-u.ac.jp/~matsu/lisp/emacs-lisp-intro-jp_toc.html マニュアル読めって言いたいんだろうけど
そうですよね。カーソル移動時にもたつくので都度IMをOFFにするのが面倒。
なにか対策があるんだろうか。また調べるか..。
(defadvice mozc-handle-event (around ad-mozc-handle-event activate)
(if (member (ad-get-arg 0) '(2 6 14 16))
(mozc-fall-back-on-default-binding (ad-get-arg 0))
ad-do-it))
どんな影響が出るかは全然調べていません。とりあえず本日はここまで。
その辺の条件を追加することができれば、使えるかもしれません。
ファイルの中身も送信しまくってるのかな？
w32-pipe-read-delay 短くしたらすごく改善されそう。
どこにも64bitに関すること述べていない
もっと、詳細に回答してあげること
ビンゴ。 setq w32-pipe-read-delayを10以下に設定するとカーソル移動が速く
なりました。この設定をすることによって、どこかに影響でないもんですかね？
まずはしばらく使ってみたいと思います。
自分は昔から 5 にしてるけど特に問題起きたことはなかったかな。
プロセスとのやりとりする時だけ使われる変数だから
migemo なんかもちょっと速くなるかと。
process-send-string 使うたびに 50ミリ秒のウェイトが入るから
mozc の場合だと何かキー押すたびに 50ミリ秒ウェイトはいるわけで
そりゃ遅くなるよね・・・
ファイルサイズでかくなって遅くなるってのはオーバーレイの処理がいまいちだからなのかな。
プロファイルとってみても mozc-cand-overlay-update が処理時間の多く占めてるし。
auto-complete で使ってる popup とかで書き換えたら速くなったりしないかな。
処理端折ってる分 overlay よりは速い気がする。
ttp://paste.lisp.org/display/144419 お前だってできるだろ、無理なら最初からEmacsなんか使うな
ぜんぜん速い。感動した。
候補の文字幅計算とか候補リストの高さとかまったく見ないで10,10にしちゃってるし、
現在の候補の位置も表示してないしアノテーションとかまるっと無視しちゃってるけど
popup 自体はそこら辺自在に設定出来ると思ったから作りこんでくれると嬉しいな。
32ビットマシンのユーザーなんで私は教示できない
> windows用公式ビルドの24.4は完全に64bitマシン対応になったのでしょうか？
>インストール時に何も特別な作業は必要ないのでしょうか？
完全に64bitマシン対応になっています。
インストール時に何も特別な作業は必要ありません。
>完全に64bitマシン対応になっています。
インストール時に何も特別な作業は必要ありません。
そのソースは？
ttp://paste.lisp.org/display/144423 mozc のキーカスタマイズはサービス側でするもんなのね。
返還中に C-f C-b とかで動かせるようにしたかったけど
キーコードしか送信出来ない上に機能とキーコードの紐付けは Google IME の設定画面上で行うという・・・
だから C-f 押したら C-d 送信するなんてので回避しても設定画面の方で変更あると動かなくなっちゃうんだな。
うぁ、これは凄い。mozcのoverlayモードど見かけ変わらず。速度高速。最高です。
カーソル移動の件もw32-pipe-read-delayの件で改善したし、W32-IMEから乗り換え
られるかもしれない。
Emacs 側の設定でこれを殺すことって出来るんだろうか・・・
IME関連のキーが好きに使えるんで便利
あるでしょうか？ 以下の設定を考えましたが、なんかエレガントじゃないので。
(unless (memq 'isearch-pre-command-hook pre-command-hook)
...)
普通に isearch-mode ではだめなん？
バッファローカルな変数だからかなぁ。
ttp://www49.atwiki.jp/ntemacs/pages/48.html の 「minibuffer に入った時、IME を OFF にする 」ってところだよね
試してみようと思ってやってみたんだけど
こっちの環境だとそもそも minibuffer に入った時に IME が ON にならない・・・
何もしないと mozc を有効にした状態で C-x C-f とかすると minibuffer で IME が ON のまま
ってことだよね？
isearch中にIMEの切り替えをするとエラーとなる。この判定をもう少しまともな
書き方にしたいなぁと。
もできる。
isearch-mode-mapにisearch-toggle-input-methodを設定するとか
ttps://github.com/iRi-E/mozc-el-extensions で、IMEの切り替えができるようになると、質問した判定が必要となる。
自分の環境だと migemo が isearch-mode の際に (set-input-method nil) してるせいで
input-method が無効になったみたい。
ちなみに emacs -q 環境で toggle-input-method をしてから C-s すると
漢字入力状態での isearch にはなった。
ただ find-file の場合ミニバッファ上では input-method が起動してない状態になるね。
ん? その emacs -q の状態が目標じゃないの?
話されていることを理解しました。例えば、find-fileを起動してIMEをONにした後、
一度抜ける。再度、find-fileをするとIMEがONの状態になっている。コレを回避
するためにminibuffer-setup-hookの設定をしています。ただ、isearchでIMEを
切り替えた時にエラーになるので、質問した判定を入れているのです。
やってみましたが、症状は同様でした。IMEの切替時にminibuffer-setup-hook
が起動し、質問の判定を入れていないとエラーとなります。
なんか、判定の仕方の質問が、大きな話となってしまったような気がする。
うーん、C-x C-f 中に toggle-input-method して適当に漢字を入力して確定、
IME on のまま C-g して find-file キャンセル、その後再度 C-x C-f したけど
IME は off になってるなぁ・・
runemacs -q でもこれは同じだった
通常状態は多分何かの設定の差なんだろうけど -q の場合で違いがあるなら気持ち悪いなあ
そちらの環境で、runemacs -q の場合はどういう挙動になります？
確かに。runemacs -qだとIMEの状態は維持されないです。なんの設定が関係している
か調べます。minibuffer-setup-hookの設定自体が必要ないのかもしれないんですね。
続きは明日かな。
いそうなことが分かりました。
ttps://github.com/iRi-E/mozc-el-extensions 明日もう少し調べます。
mozc-isearch の最後の Workaround for bug in mozc.el の部分が動作の差の原因っぽいですね。
minibuffer-setup-hook で mozc を有効にするようにしてる。
after-init-hook にその関数が突っ込まれてたから、あとから mozc-isearch を手動でロードしても
ここらへんの設定が有効にならなかったわけだ・・・
ただ、find-file 中に IME ON、一旦抜けて再度 find-file しても IME は ON のままになったけど
isearch 中に toggle-input-method しても特にエラーは発生しないみたい。
ちなみにどんなエラーが発生したんでしょう？
引数が負ならinactivateするってのが期待される動作だよね
これを直すのが一番手っ取り早い予感がする
>完全に64bitマシン対応になっています。
インストール時に何も特別な作業は必要ありません。
そのソースは？
あかん人や
のソースをお願いいたします
1. 64bitマシンを用意する
2. それにWindowsをインストールする(32bit版でかまわない)
3. 公式ビルドを普通にインストールする
461がいってるのはこういうことだろ?
そいつに触るな
でできるんだ。
アルファベット以外には効かないけど、まぁ仕方ないか。
今から調べてみますが、取り敢えずでるエラーです。長い行は後半省略しています。
Debugger entered--Lisp error: (no-catch exit nil)
throw(exit nil)
exit-minibuffer()
run-hooks(mozc-mode-end-hook)
ad-Advice-mozc-mode((lambda (&optional arg) "Minor ...
apply(ad-Advice-mozc-mode (lambda (&optional arg) "Minor ...
mozc-mode(nil)
mozc-leim-deactivate()
deactivate-input-method()
(if (>= (string-to-number emacs-version) 24.4) (deactivate-input-method) (inactivate-input-method))
(lambda nil (if (>= (string-to-number emacs-version) 24.4) ...
read-string(#("[MIGEMO] I-search [[Mozc]]: " 0 8 ...
ad-Advice-isearch-process-search-multibyte-characters(...
apply(ad-Advice-isearch-process-search-multibyte-characters ...
isearch-process-search-multibyte-characters(97 1)
isearch-printing-char(97 1)
call-interactively(isearch-printing-char nil nil)
command-execute(isearch-printing-char)
いやだから、それが大丈夫だというソースだ
その根拠を質問されているんだ
GNUサイドとして公式にWIN版24.4は64bitマシン対応になっていると発表しているのか？
ということ
その根拠を提示しなければならない
emacs-24.4のバイナリーで 32bit Windows 向けのIME対応版が欲しい。
ログみてなんでこっちで再現しないか分かった
ttp://www49.atwiki.jp/ntemacs/pages/48.html に載ってる、minibuffer-setup-hook の中から pre-command-hook でチェックしてる部分除いたバージョンじゃないとこのエラー出てこないのね
あぁ、そう。このエラーを回避するために判定を入れている。
その判定がエレガントじゃないのでということで、469の質問に遡る。
そもそもこの判定が必要のない設定のやり方があればそれでいいんだけど、
mozc-isearchのソース見ながらいろいろやってみているけどまだいい方法が
見つからないです。
mozc-isearch-use-workaround を nil にしてから mozc-isearch をロードすれば
とりあえず minibuffer で mozc の状態が残ることはなくなるようだけど、
それだと input-method と mozc-mode の状態に齟齬がでて
二度 toggle-input-method しないと mozc が有効にならなかったりすることがあるね。
ただ workaround あってもなくても色々やってるうちに二度 toggle-input-method しないと
mozc を無効にできなくなったりしたりいろいろ挙動が怪しくなるな・・・
mozc_emacs_helper.exeと463さんの設定でもはやW32-IMEに頼らなくて良くなった
ような気がする。これでLinuxと同じ土俵でemacsが使えるようになったと思うと
嬉しい。DDSKKを使っていた人は昔からそうだったんだとは思うけれども..。
quail なんかの場合、minibuffer で toggle-input-method して C-g で抜けた場合に
deactive-input-method がよばれるんだけど、mozc の場合それが呼ばれないから
current-input-method が japanese-mozc のままになっちゃう。でもなぜか mozc-mode は nil になって
齟齬がでちゃうと。
で、mozc-isearch は current-input-method の方を正として (mozc-mode t) を入れて合わせるようにしてるみたい。
挙動としては current-input-method も nil になってるべきなんだろうね。
quial だと minibuffer-exit-hook で deactivate-input-method を呼んでるから mozc もそれにならって以下でどうでしょう。
これ入れといて (setq mozc-isearch-use-workaround nil) にしてからの (require 'mozc-isearch) すれば
何もしなくても minibuffer 入った時に mozc が無効になってるはず。
あとはエラー起きた時に mozc-abort が呼ばれるみたいだけどこれも齟齬でる原因になりそう。
;; minibuffer から抜けるときに正しく input-method を無効化する
(defun mozc-exit-from-minibuffer ()
(deactivate-input-method)
(if (<= (minibuffer-depth) 1)
(remove-hook 'minibuffer-exit-hook 'mozc-exit-from-minibuffer)))
(defadvice mozc-mode (after ad-mozc-minibuffer-workaround activate)
(when (and mozc-mode
(eq (selected-window) (minibuffer-window)))
(add-hook 'minibuffer-exit-hook 'mozc-exit-from-minibuffer)))
convert を完全にシフトにしたい。
(あと、capslock を ctrl にしたい)
オレが理解できるところを超えているけど、この設定で上手く動きますね。
考えてくれてありがとう。元の（自分の）設定だと何故かUbuntuのemacs
では動かなかった（判定に引っかからなかった）んだけど、510の設定で
こちらもちゃんと動くようになりました。463の設定はibus.elと違って
Xに依存していないので、LinuxとWindowsでほぼ同じ設定で日本語入力が
できます。日本語入力環境がかなり改善しました。皆さんに感謝です。
ウィキに反映させていただきました。
ttp://www49.atwiki.jp/ntemacs/pages/48.html deactivate-input-methodの名称が変わったのが24.3からだったようなので、
その辺の対応も行いました。
emacs-24.4.exeとemacs.exeと二つあったのだが、
何か違うのか？
それと、emacs使用するときはrunemacs.exeの方を使う方が良いと
言われたのだがその理由は何？
よく分からん。
しばらく使ってみたんだけど、切り替えでエラーは出なくなったけど、
isearch で漢字を入力して確定した時に同じエラーが出るようになったね・・・
エラーなのに debug-on-error な環境でもバックトレースが出ないのはなんでなんだろう
あれ、こちらではエラーは出ていないようが気がするが..。
debug-on-errorな環境でバックトレースが出ないエラーってどんなエラー
ですかね？
比較してみたけどバイナリレベルで完全一致した。違いはファイル名だけですな。
> emacs使用するときはrunemacs.exeの方を使う方が良いと言われたのだがその理由は何？
「GUIで使うときは」の間違いでしょ。
両方ダブルクリックして起動してみればすぐに違いはわかるはず。
ありがと、emacsを起動させて
ホームディレクトリを作ったんだけど、
.emacs.dのフォルダができたのだけど、
何も入っていなくて空欄なのは問題ないのですか？
公式ビルドのをダウンロードして回答したら、libexe.bin.share.varのフォルダしかなくて
不安になっているのです。
公式ビルドのを使用するのは何分初めてなので不安なのです。
ちょっと分かった。自分のところではhelmが入っているので、find-fileすると
helmインタフェースとなる。ここで漢字を入力して確定すると、isearchと同様、
exit-minibufferがコールされ、throw 'exit がされる。でも、helm-internal
でcache 'exitとしてるのでエラーとはならない。isearchでは恐らくcache 'exit
の設定がないのでエラーとなる。
いまさらですが、cacheではなくcatchです。
急にうんともすんとも言わなくなって、どのキーボードのボタン押しても
何も動かなくなってしまった。
原因を教えてください。
素の NTEmacs は Google 日本語入力等の一部の IME を除いて
まともに動作するとは言いがたい状態です。
いろいろめんどくさいこと考えたくないんであれば
IME パッチの施してある NTEmacs を使ってくださいな。公式では存在しないから
ググってひっかかったのを使ったらいいと思う。
パッチ済みので動かなくなったんだとしたらそれはちょっとわからんです。
自分はこちらから emacs-24.4-IME-patched.zip と書かれたパッケージ化されたものを
使ってる。最新じゃないけど ATOK 2013 と組み合わせて良好に使えてるよ。
あいにく変換ボタンは付いてないので確認できないけど。
ttps://github.com/chuntaro/NTEmacs64 sskをダウンロードして適応しても、
キーボードの変換キーとか押したら
フリーズ状態のなったりするのでしょうか？
.emacsやint.elのファイルが見当たらないのですけど？
一応、フォルダオプションで隠しファイルなど見えるように設定しているのですが
どこからか別にダウンロードする必要あるのですか？
(add-to-list 'default-frame-alist '(font . "Migu 1M-11"))
として使っているのですが、&#12832; (かっこに入った漢字の一)が表示されません。
しかしemacs -qでは何らかのフォントで表示されます。
基本的にMigu 1Mを使いつつ&#12832;のような文字を
別のフォントで表示する方法はないでしょうか。
です。有難うございます。
YATEX使用目的でEMACSを使おうと考えていたので、
IMEでは不具合が出るかもしれないので避けていたのですが
大丈夫かな？
そういう挙動にはならないはずだけど、普通の IME といろいろと違うから
よくわからんうちはあんまりお勧めしないです。
勝手に生成されたりはしないので、.emacs.d フォルダの中に自分で init.el を作るしかないですね。
設定内容はググったのをコピペでいいんじゃないでしょか。
set-fontset-font のターゲットのところは文字単位も文字の範囲も指定できるから
(set-fontset-font nil '#x2460 (font-spec :name "ＭＳ ゴシック")) とかでいいんじゃないでしょか。
数字は実際に文字打ち込んで C-u C-x = で文字情報調べると出てくるのを入れればよかったかと。
勝手に作れるの？
で表示されるのを確認しました。
でも表示されない文字を見つけるたびにコードポイントとフォントを調べて
設定を追加しないといけないんじゃ大変すぎて…
表示できないときはemacs -qと同じフォントを使うようにはできないでしょうか
(add-to-list 'default-frame-alist '(font . "Migu 1M-11"))
(set-fontset-font t '#x3220 (font-spec :name "游ゴシック"))
とinit.elに設定して所望の動作をしています
けどまだ表示したい文字がたくさんあり過ぎて…
Migu 1M は set-fontset-font の TAGET を 'japanese-jisx0208 とかにして
設定すればいいんじゃないかな
(set-fontset-font "fontset-standard" 'ascii "Migu 1M-11")
(set-fontset-font t nil "メイリオ") ;; 見つからない時用のフォント
(set-face-font 'default "fontset-standard")
(add-to-list 'default-frame-alist '(font . "fontset-standard"))
あたりでうまくいくんじゃないかと。
create-fontset-from-ascii-font で新しくフォントセット作るとなんでかうまくいかなかったから
もとからある fontset-standard を利用するようにしたらうまく行った(気がする)
(set-fontset-font "fontset-standard" 'ascii "Migu 1M-11")
(set-fontset-font "fontset-standard" nil "メイリオ")
だった。いろいろ試してたらごちゃごちゃになっちゃった。
(set-fontset-font "fontset-standard" 'ascii "Migu 1M-11")
(set-fontset-font "fontset-standard" 'japanese-jisx0208 "Migu 1M-11")
(set-fontset-font "fontset-standard" 'katakana-jisx0201 "Migu 1M-11")
(set-fontset-font "fontset-standard" nil "メイリオ")
(add-to-list 'default-frame-alist '(font . "fontset-standard"))
で良さそうです
ありがとう
たとえば上の例では (set-frame-font "Migu 1M-11")
無論 default-frame-alist 中のフォント関連設定は外しておく
文字セット毎にフォント変えたいとかじゃない場合はそれで問題ないと思う。
あとなんでかその方法だと #x3220 のフォントが表示されないんだよね。
MS ゴシックだともともと表示出来る文字だから表示されるけど、
Migu 1M だと持ってない文字だから表示出来ない。
かといって M-x view-hello-file が酷いことになるのかっていうとそうでもなくて
ちゃんとアラビア語とかは別のフォントで表示されるんだよね。
良サイトはないでしょうか？
御存じの方お願いします。
emacs-23.4 が 64bit windows 上で使えるかということなら、何ら問題なく使えるじゃねのか
emacs-23.4 の 64bit 版がないかということなら、ココ hp.vector.co.jp/authors/VA052357/emacs.html 見ろよ
もっと謙虚になって調べるなり聞くなりしてから発言しろよ
キミにがっかりだよ
失礼いたしました。
そうじゃないだろ
お前が書かなきゃならないのは
っで公式が64Bit対応したっていうソースは？
だろうが
そのまま使用しても不具合など今のところ出ていないし
571のソースは何だ？
571のソースは何でしょうか？
571の根拠は？
571は敗走したのか？
571がそのソースを述べるのが先である
571のソースはまだか？
571のソースを知りたい
win用のはのいうようにinit.elはデフォルトではない
簡単に作るなら、メモ帳を起動させて、適当に一文字でもないように書き込んで
一旦、「init.txt」で名前を付けて保存して、それから拡張子を.elに変更させて
.emacs.dのところに入れておけばいい
init.elの内容はりびきち先生のサイトでも参考にすれば宜しい
↓
init.elの内容はるびきち先生のサイトでも参考にすれば宜しい
の間違いな、すまない
VS 2013 の Community Edition インストールがなんでかうまく行かなくて自分で作れない
ttp://www.emacswiki.org/emacs/DisableImeForEmacs 64bit で動かないって書いてあるけど単に 32bit と 64bit 間ではグローバルフックはまたげないってだけだと思うんだ。
時々異様とも思える興奮と執着を見せるようだが、やっぱあんま遊んでやらずに
そっとしてやったほうが、次第に自ずと落ち着きを取り戻すのだよね
Win 64bitで不具合なく動いている＝64bit OSでも動く＝64bit OSに対応している＝64bit対応
ってことではねーの
そいつ（）に触れるな
で、
「そのまま使用しても不具合など今のところ出てないし」
は公式発表なのか？
英読めないなら学校の先生にでも訳してもらえ
それでも分からなかったら自分の無能さを悔やめ
ID:WwmuKyUa0は自分の無能さを悔やめ
MFCを使っているので、expressじゃビルド出来ないね
あとx64プロジェクトは設定されてないので、ビルドには手直しが必要みたい
おそらくAutoHotKey使った方が幸せになれるとおもう
やっぱり Community Edition で MFC いれて試すしかないか。
AutoHotKey 等の Windows 全体に影響が及ぶのはあんまり使いたくなかったんだ。
頑張って自力で VS Community Edition いれるか noime パッチ版 NTEmacs コンパイルするか
我慢するかしかないかー
時々異様とも思える興奮と執着を見せるようだが、やっぱあんま構ってやらずに
そっとしてやったほうが、次第に自ずと落ち着きを取り戻すのだよね
、
> Which versions of Windows are supported?
> Emacs 24.4 is known to run on all versions of Windows from Windows 98 and Windows NT 4.0 through to Windows 7.
英語キーボード使ってるから多分なんだけど、以下ではだめだろうか。
(global-set-key (kbd "<kanji>") 'toggle-input-method)
OS 側で先にキーを見に行っちゃうからダメみたい。
ImmAssociateContext 使って IME との関連付けを無効化すればいいんだけど
同一スレッド内からじゃないとダメって縛りがあるからソースに手をいれるか
グローバルフックを使わないといけない。
結局 DIFE も AutoHotKey 的なのもグローバルフックかけてるって意味では
どのみち全体に影響はかかるよねってことで、 keyhac で Emacs の時だけ
IME まわりのキーを C-\ に置き換えることで回避にしました。
同じこと考えていました。以下で対応しました。
ttp://www49.atwiki.jp/ntemacs/pages/25.html >現在の時点では公式サイトのFAQにはWinの64bitマシンに関しての言及は一切無い。
公式サイトのFAQなんだが？
ttp://windows.microsoft.com/ja-jp/windows/32-bit-and-64-bit-windows#1TC=windows-7 >現在の時点では公式サイトのFAQにはWinの64bitマシンに関しての言及は一切無い。
上記によりは論破された
よって、以下この話題禁止
上記により===== は論破された
よって、以下この話題続行
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点を確認してここに引用してくれ
(1)に「64ビット版を除く」と書いてあるか、(2)にemacsが該当するか、分かるように頼む
color-themeやMigMix 1MやUnxUtilsも事前に必要でしょうか？
他によいのがありましたら解説お願いします。
「（除く）無い」を証明するのは「悪魔の証明」だから
説得力無し。
＞(2)にemacsが該当するか
MSサイトの該当箇所にはemacsについての一切の言及が無い
不具合が「ない」ことを求めるのは悪魔の証明だから、もうやめてくれ
(2)emacsについての言及がなくても、動かないプログラムのことは書いてある
動かないとされるプログラムに、emacsが該当しないのであれば、動くと考えて使えばよい
「64ビット版を除く」と記載がないのは不具合が発見されていないということと判断できない
「64ビット版」について記載されてない以上、不具合があっても無かったとしても記載されないのは当然
＞動かないとされるプログラムに、emacsが該当しないのであれば、動くと考えて使えばよい
動かないとされるプログラムに、emacsが該当しないかどうかも不明である。
どこのことだがわからなくてできないのか?
議論に必要だから引用してくれ
MSサイトには「emacs」について何も言及されていない
だから、「該当箇所」なんてものは存在しない
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点を確認してここに引用してくれ
説明に必要なのでお願いします
放射脳の同類
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
正論ですな
無関係ではないので引用してください
正論だな
無関係
あなたは見当違いのところを参照しているかもしれません
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点についてあなたが確認したことを引用してください
によって
>(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
修行が足りません
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点についてあなたが確認したことを「引用」してください
によって
>(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
修行が足りません
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点の質問の回答を、Emacsドキュメント・MSサイトからコピペしてください。
によって
>(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
修行が足りません
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点の質問の回答を、Emacsドキュメント・MSサイトからコピペしてください。
修行が足りません
によって
>(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
修行が足りません
(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
この2点の質問の回答を、Emacsドキュメント・MSサイトからコピペしてください。
修行が足りません
によって
>(1) Emacs公式サイト・ドキュメントに書いてある動作対象Windowsの種類は?
64bitマシンの話とは無関係
＞(2) MSサイトで64ビット機で動かないと記載の32ビットプログラムの種類は?
emacsについて何も語っておらずemacsの話とは無関係
修行が足りません
修行が足りません
.emacs.dに入れておいた方が良いフォルダは何と何でしょうか？
あと、環境設定でHOMEに指定するお勧めの場所はどこでしょうか？
解説お願いします
BINフォルダとホームディレクトリに指定した所と二つできました。
これはエラーですか？
初期化ファイルとはどちらの方に置いておいた方がよろしいですか？
両方消してもう一度起動し直してみろ
それで出来た方を使えばいい
に関しては？
デフォルトでいいと思うけど、外部プログラムと連携させる場合は、
その外部プログラムが使っているHOMEと合わせると設定が分散しなくていいと思う。
例: Emacs と msysgit を連携させる場合、msysgitのHOMEは %USERPROFILE% になるので
合わせておけば .gitconfig などが共用できる。
>例: Emacs と msysgit を連携させる場合、msysgitのHOMEは %USERPROFILE% になるので
合わせておけば .gitconfig などが共用できる。
だから、るびきち先生はC:\Users\ユーザー名をHOMEの設定に推奨してるの？
mozc-handle-event -> signal(mozc-response-error nil)
同じ問題が出て解決されている方いませんか？
具体的にどんな手順で発生するの？
使ってるけどその手のエラー吐いたことない。
helm-for-filesでimeをonにした後、単語をスペース区切りで複数高速に入力しているときになる。
指が絡まったときになりやすいような気がする。
accept-process-output が nil 返してるせいみたい。
基本的にタイムアウトの時に nil 返すんだけど、タイムアウト時間に満たない場合でも
強制的にリターンする条件があった記憶があるんだよなこれ・・・
mozc-helper-process-timeout-sec を 60 とかにすると起きなくなるような気もするけどどうでしょ。
10 だと発生するからタイムアウトが原因ってわけじゃないと思うんだよなー。
mozc-helper-process-timeout-secを60秒に設定したら、エラーの状態になった
時に固まったようになり、60秒後にエラーメッセージを吐くようになりました。
その60秒の間にC-gを打つとエラーとはならずに復旧します。根本対策ではあり
ませんが、とりあえずエラーを回避することができるようになりました。
ありがとうございます。
こっちの環境では helm-for-files-preferred-list から helm-source-locate を外しても発生しなくなった。
やっぱりプロセス呼び出してるところでなんかしら干渉してるんだろなとは思う。
helm-source-locateバリバリ使っている。なんとなく、locateの表示タイミング
と関係しているような気はしていたんだけど、外すことができない..。
バッファ内でいくら早く漢字入力をしてもエラーとはならないので、helm
の何かしらの挙動が関係しているのでしょうね。
(defadvice mozc-handle-event (before crash-test activate)
(start-process "ls" nil "ls"))
とかすると普通のバッファで入力中にも発生するようになるねえ。mozc 抜きで
cat と ls とかで発生できるようにも出来そうな気がする。
mozc の方で、レスポンス空でも signal 投げないようにどこかに advice でも付けるのはどうでしょね。
タイムアウト前なのに nil 返す現象が起きることを確認。
↓の、1秒で終了するプログラムと9999秒で終わるプログラムを起動して、9999秒の方をタイムアウト10秒で入力待ちさせる。
本来であれば10秒たってから proc-b timeout が表示されるはずが、proc-a finished とほぼ同時に proc-b timeout が表示されてしまう。
普通にタイムアウトまで待機することもあったりしていまいち再現性がないかんじ。もちろん runemacs -q 環境で。
これが仕様だったかどうかは忘れたけどなんかむかーしに変なタイミングで accept-process-output が終了する条件ってのを
読んだ記憶があるんだよなあ。
(let ((process-connection-type nil))
(setq finish-a 1)
(setq wait 10)
(setq proc-a (start-process "proc-a" nil "sleep" (number-to-string finish-a)))
(setq proc-b (start-process "proc-b" nil "sleep" "9999"))
(set-process-sentinel proc-a (lambda (p s) (message "%s : proc-a finished"
(current-time-string))))
(set-process-sentinel proc-b (lambda (p s) (message "%s : proc-b finished"
(current-time-string))))
(message "==============")
(message "%s : start" (current-time-string))
(if (accept-process-output proc-b wait)
(message "%s : proc-b return t" (current-time-string))
(message "%s : proc-b timeout" (current-time-string)))
(message "....and kill proc-b")
(kill-process proc-b))
現象の再現までしてくれてありがとう。根本的な対応ができる策がないか、
調べてみようと思います。
できるけど、まだエラーとなるパターンがある。調査継続。
(defadvice mozc-helper-process-recv-response (around ad-mozc-helper-process-recv-response activate)
(catch 'exit
(dotimes (i 10)
ad-do-it
(if ad-return-value
(throw 'exit t)))))
ttp://debbugs.gnu.org/cgi/bugreport.cgi?bug=17647 これが仕様なんだとすると、額面通りタイムアウトをタイムアウトと捉えないで
エディタに制御を返すまでの時間と捉えて必要な値が揃うまでずっとループにしたほうがいいのかもしれんね。
migemo.el なんかはそういう実装になってるし。
それはそうと helm-for-files(というか helm-locate-source) と mozc 一緒に使うと色々ひどいことになるな。
変換中のスペースキーまで helm が補足する上にミニバッファ上の変換候補一覧までパターンに取り込まれて検索されちゃう。
検索したところで 1.カンジ 2.勘次 なんてファイルはないから候補にはでないにしても
ずいぶんと無駄に locate が走ってることになる。
バグなんですね。
helm-locate-sourceを使うときはidel-delayの設定は必須のような気がします。
mozc + helm-for-files でもそれっぽい状況が再現したわ。
locate のデータベースがない状態 + mozc のサジェストも切った状態で
helm-for-files 起動してスペースおしっぱなしするとどっかの時点で
locate か mozc_emacs_helper を kill しないと emacs が固まる状態になる。
わけがわからなくなりつつあるが、mozcに対応したand検索可能な
helm-locate-commandの設定を作ってみた。mozcは入力文字の
確定前には*（と二行目に変換パターン）を返してくるようで、この*が
バッファ側の検索にヒットしたりするが、これはhelm-locate-command
では対応できないのでガマン。
(setq helm-locate-command
(concat "locate_case=$(echo '%s' | sed 's/-//'); locate '' |"
"perl -ne \"$(echo \"%s\" | head -n 1 |"
"sed -r -e 's/\\*/<notMatch>/' "
"-e 's/^ +//' "
"-e 's/ +$//' "
"-e 's_/_\\\\/_g' "
"-e 's_( |\\.\\*)+_/'$locate_case' \\&\\& /_g' "
"-e 's_.*_$| = 1; print if (/&/'$locate_case')_')\" |"
"head -n " (number-to-string helm-candidate-number-limit)))
ものすごい力技だｗ
mozc-isearch で preedit が空の時発動する hook (=入力確定時に発動するフック) が作られてるけど
preedit が空じゃない時に発動する hook もついでに作って、そこの間だけ設定される変数作って
その間だけ helm の逐次検索を無効にするとか出来ないもんだろか。
helm ちょろっと見ただけじゃ何をどうしたら逐次検索止められるのかわからない。
あと、GoogleIMEJaTool.exe に引数与えれば単語登録用のダイアログとか表示出来ることはわかったんだけど、
これ用の mozc_emacs_helper みたいなのってないんだろか。
出来れば emacs の中から単語登録したい・・
これで入力確定前に無駄に検索が走らないようになると思う。
入力が確定した時点で検索が開始するようにはしている。
mozc 起動時点で強制的に suspend したり、もともと suspend されてたかどうかは無視してたり
helm と関係ないところでもいちいち helm のステータス変えてたりと改良の余地は多いにあると思う。
ttp://paste.lisp.org/display/144519 unxutilsをインストール時に絶対に必要でしょうか？
それが無いとSKKインストールできないと聞いたんですが。
README に確かにそう書いてあるけど、tar と gzip はアーカイブを解凍するときに使うだけだから
自分で適当な解凍ソフト持ってれば問題ないし、make も README の下の方まで読むと
makeit.bat を使う場合、って項目があるからそれに則って作業すれば必要ないよ。
ありがとうございます。
makeit.batの方法でコマンドプロンプトで
MAKE INSTALLをしたんですけど、
DEFAULT_MAKE_ARG に install を入れててした方が
エラーが出ずにできましたので、READMEでそれを最初から推奨した方が良いと思いますね。
最初、それをせずにしたら、make1.batの箇所でエラーが出ました。
いい加減、SkK信仰止めよ
いいサイトある?
emacsがあれば安定したskkが使える(少なくともvimの方はバグがきつい)ので、
将来mozcとかAtokとか消えることがあってもemacsのskkで立ち回れるようにしておいて
安全を確保したいのだが、慣れてないためかなかなか速度が上がらない
いまだに、何処から送り仮名にするとかその次元で手間取っている
慣れの問題だし沢山入力するしかないとは思うけど。
SandS にするとか違った設定知りたいとかなら skk スレあたりで聞いてみたらいい。
もっといい加減なの作ってみた。とりあえず動いている。
(defadvice mozc-candidate-dispatch (before ad-mozc-candidate-dispatch activate)
(if (helm-alive-p)
(let ((method (ad-get-arg 0)))
(cond ((eq method 'update)
(unless helm-suspend-update-flag
(helm-kill-async-processes)
(setq helm-pattern "")
(setq helm-suspend-update-flag t)))
((eq method 'clean-up)
(if helm-suspend-update-flag
(setq helm-suspend-update-flag nil)))))))
やはりここで聞いて良かったよ
SandSなんてものがあるんだな
今、変換にAltを、CapsにCtrlを当てていて
無変換には'-'を当てていた。
カタカナの外来語ではそこそこ使うし、>664のようにそこそこ使うから腐らない配置だと思っていた
キー配置というものを再考察してみる
helm-alive-p なんてあったのか
これ入れとけば helm 関係ないときまで余計な操作はいらなくていいね
ddskkは絶対便利な設定が互換性の為にデフォでオフられてたりするから
そういうを改善する便利設定をまとめたりするんで、ちょっと待ってて
それすればMS-IMEとほとんど同じように使える (もちろん根本的な能力はskkだが…)
さすがにNTEmacs関係ないSKK固有の設定の話は
SKKスレでやってくんない?
色々披露したい気持ちはわからんでもないけどちとうざい。
じゃあmozc.elの話しもmozc.elスレでやるべきだし禁止なw
locateの問題も結局NTEmacsだけの問題じゃないことが判明したんだし当然でしょ。
問題の切り分けまではともかくhelmとの共存とかWindows固有じゃないし。
そもそもmozc.el自体Windowsとは何も関係無い
最初からスレチだろ
NTEmacsは日本語入力が不自由だからmozc.elやDDSKKの話しが出てんだ
は設定をMS-IMEに近づけると言ってる
どっから関係無いと言えるのか、定義をはっきりしろ
なに言ってんだ？
Windowsで使えなかったmozcをNTEmacsで使えるようにしたってのがmozcの話の発端だぞ? どこがWindows関係ないんだ?
helmとのからみはもはやWindowsと関係ないからスレチと言っている。
最初からWindowsで動くSKKの便利設定晒す程度のと一緒にするなよ。
あるぞー
Emacs 以外の skkime とかの話も出るけどね
SKKとその派生入力メソッド
ttp://anago.2ch.net/test/read.cgi/software/1328329402/
mozcをWindowsで動かす
Windowsで動いているSKK
結局どっちを話したってWindowsと関係している以上一緒だろ
そのSKKの設定とやらはWindows固有なのか?
普通のEmacsでしかできなかった何かをNTEmacsにもたらしたり
NTEmacsでしかできない何かを実現したりする何かなのか?
Windows上で動いてるSKKじゃないとできない話なのか?
違うだろ? 全然一緒の話じゃないよ。
NTEmacs と関係のないくだらない話を延々してるのはお前だよ。
黙ってろ。
mozc_emacs_helper と skk の悪魔合体の方はひらがなの状態じゃ受付ないから諦めた
設定貼ったら貼ったでまた同じやり取り続くんだと思うとうんざりする
別に俺が目立ちたいから設定を上げたいとかじゃなくて、少しでもDDSKKを使う人の敷居を下げたかっただけなんだがな
ちゃんと反省して二度とするんじゃないぞ。
スレチとは全く思ってないよ
つうか俺は変な奴にからまれてたんだなw
ここから何かしら役に立つ情報がアップされれば楽しいし、NTEmacsが
過疎化するより賑わっていたほうがいい。自分は2chに命掛けている訳
でないので、普段は眺めている程度。でもその中に有益な情報を見つけ
たりするとこのスレを見ていて良かったと思う。スレ違いってのは、
ある程度は守る必要のあることなのだとは思うけれども、あまり厳密に
線引しようとして皆が投稿を躊躇するようになると、過疎スレになって
しまうようで悲しい。
skk も mozc も使ってないし他所でやってほしいわ
どうせこいつらこないだ延々 64bit がどうのとかやり直しがどうのとか言ってた連中っしょ
単純に./autogen.shして./configureしてmake bootstrapでビルドできるのね
ってことはEmacs 25になればWin64の公式バイナリが配布されるようになるのかな
システムタイプのMINGW64が追加されたからだな
しかし25は1年後か2年後か…細かい機能追加はあるけどメジャーバージョンアップする程の大物がないからなぁ
いつになっても洗練・改善されていかないんだ
不平不満も技術向上に一役買っている事を理解すべきだ
と思うようになったよ
ゴミみたいな設定書かれるぐらいなら黙っててくれたほうがありがたい。
そういう意味で見たいな基地外にも存在意義はあったといえる。
自己顕示欲を滲ませざるをえないあたりがもうね
ゴミみたいな設定書かれるぐらいなら黙っててくれたほうがありがたい。
そういう意味で見たいな基地外にも存在意義はあったといえる。
emacs-24も取得して試してみましたが、こちらは24.4と同様に./configureがx86_64-pc-mingw32なんて知らんと言ってこけますね。
masterのWin64対応の部分がemacs-24にマージされると嬉しいのですが。
たださらっと書いているLispが読めなくて悲しい
ttp://www.math.s.chiba-u.ac.jp/~matsu/lisp/emacs-lisp-intro-jp_toc.html おすすめやで。
ttps://gist.github.com/rzl24ozi に 24.4 に対する各種パッチあり 中に emacs-24.4-w32-ime.diff (
ttps://gist.github.com/rzl24ozi/a282260d2dd136daab14 ) も README (
ttps://gist.github.com/rzl24ozi/1dd94943f638e84ef1c0 ) によれば 「ファイル名に x64 がついてるが 32bit 版でも使用できる」と
これで 32bit版 Windows 用 IME-patched NTEmacs-24.4 がビルドできそう？
自ビル力なく見守るだけなのが歯がゆいが期待は持ち続けたい、、、
のファイルがインラインメソッドでセーブできなくなりました。原因を調査して
いくと、tramp-sh.elの中にbase64 -d -i <<'XXXXX' みたいにしてヒアドキュメント
を利用したデコード処理をしている箇所があって、このコマンドがfakecygpty経由の
プロセスが実行されているバッファに送信（process-send-string）されると、
一定のサイズ以上のヒアドキュメントの入力があった場合にフリーズするようです。
fakecygpty経由で起動したshellバッファでも同様な問題が発生することを確認して
いますが、emacs-24.3や24.2ではこの問題は発生しません。また、fakecygptyを
経由しないshellバッファでも発生しません。
以下で"aaa.."の行を53行くらいまで増やすと再現するのですが、この件について
何か情報お持ちの方いませんか？
cat << EOF
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
EOF
ヒアドキュメントじゃなくても一度に渡すデータ量が多いとか貯まるね。
一度に渡すデータサイズが 4096 超えた時点で固まるみたい。
(let ((n 4096))
(concat "echo " (make-string (- n (length "echo j\n")) ?x) "j"))
これをコピーして実行するだけなら問題ないんだけど、4097 にしたり
貼り付けたあと何か文字追加したりして実行すると固まる。
ansi-term だと改行周りの誤差のせいか 4097 は通るけど 4098 で固まる。(自分の環境では)
はじめは fakecygpty の内部バッファかと思ったけど
何もいじってない fakecygpty は 1024 だからそこらへんはあんまり関係なさそうだねえ。
ただtty回りがcygwinみたいにfakecygptyで偽装できないから
鍵有：sshx or scpx
鍵無(パスワード認証)：plink or pscp
ってな感じで妥協しなきゃならんが
なんかうまい方法ないもんかな
確認ありがとう。まさに4096バイトでした。4Kといえばpipeのバッファの
サイズのような気がしますが、何か関係するんですかね？
今は、取り敢えず以下で逃げていますが、なんとかならないものかと。
(setq tramp-copy-size-limit 2900)
ただし一行のサイズが 4096 を超えれば、だけど。
これは 24.3 でも 24.4 でも同じだった。
↓を実行すると1文字も出力を受け取れないまま cat が終了しちゃう。
4095 ならちゃんと xx...xxx を出力して入力待ちになる。
4097 だと何故か4096バイト読み飛ばして x を出力して終了しちゃう。
(let ((process-connection-type 'tty))
(send-string (start-process "cat" "*cat*" "/bin/cat")
(concat (make-string 4096 ?x) "\n")))
ちなみに process-connection-type を nil にしてパイプ接続なら問題なかった。
＃余談だけど NTEmacs の fakecygpty の設定のところも、process-connection-type を見て
＃nil なら fakecygpty を使わないで起動するようにした方がいいと思う
コンソールで単に cat を実行して改行なしの 4097 バイト貼り付けた場合も
Ctrl-D での EOF 送信が出来なくなったから tty の行バッファのサイズなのかなぁ。
途中に改行入ってれば当然だけど何バイト送っても問題なかったし。
どうやって行バッファのサイズ調べるんだっけ・・・
とはいえ、tty が原因だとしても Emacs と fakecygpty 間はもともとパイプ接続だし
fakecygpty と shell 間の接続は Emacs のバージョンアップ関係ないからなあ。
なんなんだろうねえ。
↓のシンプルな入力を待って出力するコードでも同じように 4096 バイト送ると停止しちゃう。
ttp://codepad.org/GSCZFx8n なんかあんまり変わってるイメージなかったけど 24.4 はプロセス I/O 絡みにも手が入ってたのね・・・
Fedora19で試してみた
のcatは速攻Process select finishedで終了したが、の自前コマンドは
char buf[1024];だと空のstart endが2回繰り返されたあと、1024ずつ4回xが表示された
select start
select done
select start
select done
x(*1024個)select start(※0)
select done(※1)
※0と※1があと3回繰り返し
char buf[1024*8];
でやると、
select start
select done
select start
select done
Process select finished
タイミングの問題な気がする…
emacs のソース見てみたけど、windows 用の write に変更があったみたいで
パイプが満タンになるとブロックして子プロセスの出力を待つ、って処理が追加されてた。
どうもこれが原因なんじゃないかなあ。
emacs にいちいち手を入れるわけにもいかないし fakecygpty 側でなんとか回避する方法
考えないとだねえ・・・うーむ
・w32-pipe-read-delay を 0 にする
・Cygwin 1.7.34-002 (32bit) を使う
・Cygwin を 64bit版にする
のいずれかで動くかもしれない。
ちなみにCygwin64版Emacsでは問題がないように見える。
まぁ現象が多少違うようだけど、Linux版でもおかしな事になってるから
NTEmacs固有の話ではなくEmacs全部に関係する問題だな
char buf[1024];で4回に分けてreadすると1個足りずに4096-1個のxしか受け取れてなかった
ttps://lists.gnu.org/archive/html/bug-gnu-emacs/2014-09/msg00182.html 今回のと同じように NTEmacs 使用中に非同期IO中のパイプに大量にデータ流し込むと
デッドロックが起きるって話とそれを解消するパッチ。
このパッチで件のスレッドで発生する問題はクリアしたんだろうけど
別な問題が出たんじゃないかなあ。
ちゃんと修正追ってないからまだなんとも言えないけど。
消極的な回避方法としては、
tty 使用時の process-send-string において適当な長さで分割送信する advice でもつけてやればいいんだろうなとは思う。
改行と C-d の送信位置によって EOF 送信されない問題とかあるけど、
もともとの fakecygpty からしてそこらへんまじめに処理はしてないし
そもそも cygwin と linux の挙動も違うからあんまり神経質になることもないかなと。
あーこれね
これのおかげでtss(TypeScript用インテリセンス)をNTEmacsで使うと必ずデッドロックが起きるようになったよ…
Linuxでは問題ないからパッチのせいだと思うんだよなぁ (単なる愚痴だが)
ちなみにで24.3でもなると書いてあるから、問題はいろいろありそうだ
Linux で発生する事象は一行が 4096 超えた場合でかつ tty 限定だから
それが問題になることはあんまないんじゃないかなぁ。
ソケットやパイプでは改行ない大量データもありうるけどどうも発生しないみたいだし。
gnome のターミナルで cat に対して 4096超えるサイズの改行なしデータ貼り付けてみたけど
出力側だけ終了してプロンプトが出るけど入力は cat に吸われるみたいな変な状態になったから
Emacs が変っていうより tty の仕様かバグなんじゃあるまいか。
それを解消するようなパッチは既に取り込まれてるんだけどまたこれとは違った話なのかねえ。
ttps://lkml.org/lkml/2013/11/22/134 ck とか mintty の場合貼り付けした時点で 256 バイト毎に切り分けされてた。
ここらへん linux と cygwin の tty の仕様の違いなんだろうけど
256 は tty 行編集バッファの最大値から来てるようだからこっちの方が自然な感じもする。
tss が固まるのはなんでなんだろね？やっぱりそれも大量データ絡みなんだろか？
> gnome のターミナルで cat に対して 4096超えるサイズの改行なしデータ貼り付けてみたけど
> 出力側だけ終了してプロンプトが出るけど入力は cat に吸われるみたいな変な状態になったから
なんと！Linuxの症状は完全に別の問題だ
いやー勉強になったありがとう
tssはかなり大量のデータをパイプ経由で送受信するから同じ問題っぽい
だとするとやっぱりのパッチが影響してる可能性が高い
ひどいエンバグだ…
以下でどうでしょうね。
fakecygpty 通さない場合でも select 使って入力の多重化してるプログラムの場合
同じ問題起きる可能性があるから全プロセスに適用しちゃっても問題ない気はする。
一応境界での漢字またぎはテストしたけど tss とか tramp で動くかどうかはちょっとわからない。
(defconst w32-pipe-limit 4096)
(defadvice process-send-string (around workaround-for-process-send-string activate)
(if (not (eq (process-type (ad-get-arg 0)) 'real))
ad-do-it
(let* ((proc (or (ad-get-arg 0)
(get-buffer-process (current-buffer))))
(rest (encode-coding-string (ad-get-arg 1)
(cdr (process-coding-system (get-process proc)))))
(coding-system-for-write 'no-conversion))
(while (> (length rest) w32-pipe-limit)
(ad-set-arg 1 (substring rest 0 w32-pipe-limit))
ad-do-it
(setq rest (substring rest w32-pipe-limit)))
(ad-set-arg 1 rest)
ad-do-it)))
問題提起したものです。trampで動きました。先にencodeしてno-conversionで
渡す方法を取れば、byte計算ができるんですね。思いつきませんでした。
この対策でしばらく使ってみたいと思います。
原因調査や対策案を考えてくれた皆さんに感謝です。
遅くなったがNTEmacs+tssは駄目だったよ…
これは別の原因か
パッチ側にずっと問題があるままになっている？
cygwin 上でコンパイルした node.js なのか windows 用なのかで違ってくるのかも？
ちょっと試してみるか。
最新版はサポートされてないっていうから古いバージョン落としてきたけど
今度は cygwin64 サポートされてなかったという
> IMEパッチ版て24.3, 24.4でも日本語入力してるとエラー落ちすることないですか？
24.3では時々ある。
24.4は chuntaro/NTEmacs64 を使ってて いまのところ落ちることない
> パッチ側にずっと問題があるままになっている？
何のことか 俺にはさっぱり ご勘弁を
うちもそんな感じ。gnupackのemacs-24.3-20130317までは正常に動作するけど、
それ以降は日本語入力時にたまに落ちる。
chuntaro/NTEmacs64のime版でも落ちる。
そろそろ仕様変更に追従しきれなくなってきたとかなんじゃないのかね
24.4 から w32-unicode-filenames なんて変数増えてたのな
結構細かくかわってるなー
プロセスに関してはあくまで start-process する時の coding-system 決定に使われるだけのようだわ。
migemo を fakecygpty 非経由で使ってるんだけど 入れてると何故か CR が余計に送られるんで
なんでだろうと思ったら二度 encode されてて問題が発覚したよ。
unwind-protect でエラー対策して set-process-coding-system で変更じゃないとダメみたい。
scp のは基本 ascii 文字だから特に問題起きなかったんだろね。
自動エンコードが行われなくなってわざわざ no-conversion 指定してやる必要もないみたいだね
改行だけは変更されるからそこだけ考慮する必要はあるみたいだけど
encode-coding-stringをする前にinhibit-eol-conversionをtに束縛するのはどう？
encode で unibyte にした後と process-send-string する前の間でよさそう。
そうすれば最初の encode で全部の変換が完了して、
process-send-string はまったく変換を行わない状態になるはず。
自分は↓の16進ダンプするプログラム作ってテストしてみたよ。
一度の送信に対して一行ダンプするって挙動で、同じ文字が連続してる場合は回数表示するって感じで。
ttp://codepad.org/SknURbty あとは fakecygpty 切った状態のこれに対して
(set-process-coding-system proc 'undecided-dos 'utf-8-unix)
(sent-process-string proc (concat (make-string ?x 4095) "あ\n"))
(set-process-coding-system proc 'undecided-dos 'cp932-dos)
....
とかで境界チェックとかエンコードチェックしてみたりした。
今までの分、1500円ぐらいで全部みれないのかなぁ
一ヶ月分500円ちょいはちょっと高いよ…
テストしてみました。以下の順番で進んでいくと、最後から３番目の結果が
おかしくなります。なぜだろう？ emacsのバグ？
(set-process-coding-system proc 'undecided-dos 'cp932-dos)
(process-send-string proc "あ\n")
(process-send-string proc (encode-coding-string "あ\n" 'cp932-dos))
(let ((send-string (encode-coding-string "あ\n" 'cp932-dos)))
(let ((inhibit-eol-conversion t))
(process-send-string proc send-string)))
(process-send-string proc (encode-coding-string "あ\n" 'cp932-dos))
(process-send-string proc "あ\n")
(process-send-string proc (encode-coding-string "あ\n" 'cp932-dos))
自分ところで試したら以下の結果になりました。
例によってfakecygpty 切った状態。
process-send-string は以下
ttp://paste.lisp.org/display/144800 82 a0 0d 0a
82 a0 0d(2) 0a
82 a0 0d 0a
82 a0 0d(2) 0a
82 a0 0d 0a
82 a0 0d(2) 0a
0d が２つ続くのは unibyte 文字列 82 a0 \r\n に対して更に cp932-dos の変換がかかるわけだから
挙動として正しいと思う。
82 a0 0d 0a
82 a0 0d(2) 0a
82 a0 0d 0a
82 a0 0d 0a
82 a0 0d 0a
82 a0 0d(2) 0a
確かに 0d が一個だけになってる。これはなんでだろう？
マルチバイト→ユニバイトの、マルチバイト→マルチバイト、ユニバイト→マルチバイトの場合は
ちゃんと inhibit-eol-conversion とプロセスの改行タイプにあった出力になるから
ユニバイト→ユニバイトの場合だけおかしいのはバグじゃないかと。
端折った説明なんで process.c の send_process() と coding.c の setup_coding_system()、raw_text_coding_system() あたりを参照して欲しいけど
挙動としては以下のような感じ。
process-send-string は送信時に以下の流れで処理が走るんだけど
1)現在の coding-system を見て必要であれば coding-system のセットアップ
2)現在の coding-system を見てエンコード要フラグがたってればエンコーディング
3)実際の送信
前回の送信時の coding-system の状態が raw-text-unix 相当だと 1) 2) が不要ってみなされてそのまんま送信されちゃう。
ユニバイト文字列を送る際、1) のところで coding-system が raw-text-(改行コード引き継ぎ) に更新されるんだけど、
これが raw-text-unix、もしくは raw-text で inihibit-eol-conversion t になる場合、coding-system のエンコード要フラグが不要に設定される。
すると次のユニバイト文字列送信は 1) のところでエンコード要フラグがたってないから coding-system が更新されず、
coding-system が更新されないので 2) もスルーされて process-coding-system や inhibit-eol-conversion に依った改行コードの変換処理が走らず
LF が LF のまま出力されちゃう。
inihibit-eol-conversionは使わない方がいいのかな。ピッタリの解決方法だった
んだけど。
今回の 4096 バグ用 advice いれると
のバグっぽい挙動も治るし問題ないんじゃないかなぁ。
の挙動に依存してるコードはまずないんじゃないかと思うし。
他の対策も浮かばないので今回の対策まま使ってみようと思う。
これで３件の不具合発見となります。結構潜んでいるもんだなぁ。
・accept-process-output関連バグ（
ttp://debbugs.gnu.org/cgi/bugreport.cgi?bug=17647） ・select関連バグ（
ttps://lists.gnu.org/archive/html/bug-gnu-emacs/2014-09/msg00182.html） ・process-send-string関連バグ
出来るんでは。
ここらへんは ntemacs に限らずみんなそれなりに腐心してることだろうから
本スレで聞いてみるといいんじゃないかな。
拡張がないならないでそれなりに動くようにしたいとか、
なかったら勝手にインストールさせたいとか、
emacs のバージョンが様々だとか、
USB にいれてポータブル emacs にしたいとかで
設定の内容も変わってくるしね。
環境ごとに定義される変数があるので、それで設定は分岐出来る
複数環境の同期のために、gitにinitあげてる人もいるから、参考にしたら
ありがとうございます。色々調べてみます。
背景としては、職場が変わった際に、Emacs自体はダウンロードできても（それは許可をもらってる）、
環境面を移行することが難しい（USBとかNGなので）のと、一から作るのも大変なので、
init.elの中身を、会社のWebMailの本文にコピペ（添付はできないので）して、
それを別途職場でWebMail経由で本文をコピペしてinit.elを作成して、
あとは起動させて、パッケージとか自動的に落として環境面を整えられたら。。。と思った次第です。
今は標準で package.el が入ってるから
下の方にあるインストールされてないパッケージをインストールするって部分を
自分なりに手を加えてつかったらいいんじゃないかな
ttp://emacs-jp.github.io/packages/package-management/package-el.html パッケージインストールするパッケージは他にも el-get とか auto-install とか cask とか
色々あるけど、流行ってる cask なんかは python のインストールも必要だったりするから
あんまり Windows 環境向けではなかったと思う
おお！情報ありがとうございます。
合わせて、今までxyzzy使って（Windowsキーバインドで）ましたが、
頑張ってEmacsを勉強します（キーバインドを覚えるのが大変ですが）
わざわざ業務用になんでこんな苦行を…
仕事ではWindowsですが、今後、自宅ではWindowsとMacの両方を扱いたいな〜と思ってますので
（最近のThinkPadがクソなのでMacBookProに変えようか検討中）
それともxyzzyを貫いたほうがいいですかね？
（確かに動作速度はEmacsは重いのがネック）
Win と Mac で同じの使いたいだけなら vim も Atom も Sublime Text系もあるし。
ただ、Emacs のキーバインドって機能名の頭文字からとってるぐらいだから
決して押しやすさを考えた良いキーバインドではないと思う。
xkeymacs とかで頑張って Windows 全体で Emacs のキーバインド使えるようにしなきゃいけないってのは
個人的には呪いみたいなもんだと思ってる。
も書いているけど、emacsキーバインドを覚えてしまうと他に移行するのが難しい体になってしまうので止めた方が良いかもしれん
Macでxkeymacsみたいなアプリもないしw
(キーバインドはemacs)
最初winでの操作を快適にするため、ahk使ってemacsバインドにしていたけど、
慣れれば使い分けは問題なかった
vimも使っていた時期があるけど、独自カスタマイズに慣れると、素のvimが使いにくくなるので辞めてしまった
ドットファイルは dired-listing-switches から a とか A を外せば隠せるんだけど。
desktop.ini とか見たくもないのに出てくるのはあんまり嬉しくないよね。間違って消したりしたくないし。
勝手に ls-lisp 使われちゃうんだな。
ls-lisp-use-insert-directory-program を t にしたら cygwin の ls 使われるようになったけど
(set-file-name-coding-system 'cp932) してるせいで utf-8 環境だとしっかり文字化けしてくれた。
にもあるとおり、どっちにしろ UTF-8 でファイル名が保存されてること考えると
24.4 以降はほんとに (prefer-coding-system 'utf-8-dos) だけで良くなりそう。
というかそもそも何の設定もしなければ language-environment は "Japanese" になってるし
default-*-coding-system も utf-8-dos とかになってるんだね。
LANG 設定しなくても chcp 1250 とかしても language-environment が "Japanese" になるのは
一体どこ見て設定変えてきてるんだろう・・・・？
LC_ALL が UTF-8 だから coding-system 系が軒並み utf-8 になってただけだった
環境変数すら設定してないと cp932 になっちゃうね
あと勝手に current-language-environment が Japanese になるのは
Windows の場合システムロケールから環境変数 LANG のデフォルト値を設定してて
それを読んでの結果だったみたい
ls-lisp 側でなんとかしてみた
dired-mode で C-u s で ls のスイッチ変更したときに a を外すと
ドットファイルの他に Windows の隠しファイルも消えるようになる
a をトグルする関数あってもよさそうなもんなのにないんだな
ソートも name と date だけじゃなく extension とかでもやりたくなるような気もするんだけど
そこら辺も C-u s で都度書いてねなのね
(defun list-hidden-files (dir)
(with-temp-buffer
(when (eq 0 (call-process "cmd" nil (current-buffer) nil
"/c" "dir" "/ah" "/b"
(subst-char-in-string ?/ ?\\ (expand-file-name dir))))
(delete "" (split-string (buffer-string) "\r?\n")))))
(defadvice ls-lisp-handle-switches (before hide-hidden-files activate)
(unless (or (memq ?a (ad-get-arg 1))
(memq ?A (ad-get-arg 1)))
(ad-set-arg 0 (ls-lisp-delete-matching
(concat "^"
(regexp-opt (list-hidden-files default-directory))
"$")
(ad-get-arg 0)))))
ttp://d.hatena.ne.jp/ksugita0510/20141229 いらない子
Warning: arch-dependent data dir `/app/cygwin/emacs/libexec/emacs/24.4/i686-pc-cygwin/': No such file or directory
Warning: arch-independent data dir `/app/cygwin/emacs/share/emacs/24.4/etc/': No such file or directory
Warning: Lisp directory `/app/cygwin/emacs/share/emacs/24.4/lisp': No such file or directory
Error: charsets directory not found:
/app/cygwin/emacs/share/emacs/24.4/etc/charsets
Emacs will not function correctly without the character map files.
Please check your installation!
環境変数ROOT_DIR定義してもダメっぽい
プライベートフォントが使えるかどうかぐらいな気がする
32-bit 版の 24.4 を待っていた。
う〜ん・・・
せっかく更新してくれた作者さんには悪いけど
cygwinバイナリなら要らないなぁ…
実はそんなに無い気もするけどね
NTEmacs単体で利用する場合にはinit.elはどこに置くことになるの？
gnupackはhome/.emacs.d/にinit.elを置くよ
環境変数 USERPROFILE または HOME の設定されてる場所の .emacs.d 以下だね
環境変数はレジストリの HKLM/Software/GNU/Emacs に設定しても読んでくれたはず
自分は cygwin も NTEmacs も Windows のドキュメントフォルダをホームにしてるな
なるほど、そういうことか
ありがとう
cygwinバイナリだと、fakecygptyは要らなくなるのかな。あとtrampもsshxや
scpxでなくsshやscpで動くようになりそう。ただ、WindowsのパスやUNCのパスを
そのまま利用できない。これを許容できるかどうかのような気がする。
fakecygpty は普通に不要になるし、前にこのスレで出てた4096バイト以上パイプに詰まると
固まる問題なんかも発生しなくなる
地味に嬉しいのは emacs -nw が cygwin の端末上で使えるようになる部分かね
NTEmacs だと cmd 上じゃないとうごかなかったからなぁ
Windowsのパス絡みの問題は・・・ホーム以下のファイルをメインで編集してるなら
そう問題にならなそうではあるよね
UNCパスは頑張ってマウントしまくることで対処になるんだろか
「NTEmacs単体で利用」では、 の状況起きないの？どう回避するの？
etc が見つからないのとかは↓を参考に EMACSDATA とかの環境変数適切に設定してあげれば出来るのかもしれない。
arch-dependent data dir は PATH の設定で回避できるんかねえ。
ttp://www.gnu.org/software/emacs/manual/html_node/emacs/General-Variables.html#General-Variables ただ、 emacs ディレクトリだけ抜き出して直接 runemacs とか起動した場合、ルートがどこになるのとか
cygwin の /etc 以下なくて大丈夫なのかとか色々不安な感じもするな。
ルートディレクトリの位置って cygwin1.dll の場所から逆算されてるんかねえ。
まさに「IME パッチのあたった 32bit 版が欲しいってだけ」というクチ。
64bit 版には chuntaro/NTEmacs64 を即ありがたく使えてるが、
32bit に使ってる 24.3 ( d.hatena.ne.jp/ksugita0510/20130503 ) と同じスレの
( d.hatena.ne.jp/ksugita0510/20141229 ) ページの宣告の下、
些か無謀な自助努力としての だった。
> etc が見つからないのとかは↓を参考に EMACSDATA とかの環境変数適切に設定
については、emacs が Windows ドライブ名 (「C:」) 認識しない、
それを抜くと と同じエラー。
環境変数は cygwin のパスで指定しなきゃいけないし、ドライブレター抜いてもそりゃ DOS のパスだから無理でしょう。
なので cygwin のルートディレクトリからのパスで指定しなきゃいけないわけなんだが
cygwin は cygwin1.dll の場所を起点にルートディレクトリを決定してる模様。
たとえば cygwin1.dll を c:\emacs\bin 以下にいれたんだとすると、c:\emacs が cygwin での / になるので
EMACSDATA は /share/emacs/24.4/etc を指定してやればいい。
同様に EMACSPATH は /bin、EMACSLISP は /share/emacs/24.4/lisp あたり指定してやればいいんじゃないかね。
それでとりあえず起動はしたけど dired 動かすだけでも ls がないだの df がないだの言われて結構一苦労な感じ。
システムコール絡みでいちいちcygwinのがわを通さなくちゃいけないからなのかな
指導ありがと。
【応答・討論】
> cygwin は cygwin1.dll の場所を起点にルートディレクトリを決定してる模様。
> たとえば cygwin1.dll を c:\emacs\bin 以下にいれたんだとすると、c:\emacs が cygwin での / になるのでEMACSDATA は /share/emacs/24.4/etc を指定してやればいい。
そのようにした。
> 同様に EMACSPATH は /bin、EMACSLISP は /share/emacs/24.4/lisp あたり指定してやればいいんじゃないかね。
EMACSPATH はどうも exec-directory (architecture-dependent file へのパス) の初期値を与える。(exec-path の一部にはなるが)
/bin (emacs の場所) について、NTEmacs では invocation-directory の初期値に設定されてたが、この Emacs ではそれがなぜか /usr/bin になってる。
いずれ、/bin が必要であれば PATH に入れるか .emacs (init.el) で直接 exec-path に含めるのがよいかと。
EMACSLISP は EMACSLOADPATH のことなのね。それをそうした。
ついでに site-lisp も load-path の初期値に含まれないようだから、これらも含めて指定。
> それでとりあえず起動はしたけど dired 動かすだけでも ls がないだの df がないだの言われて結構一苦労な感じ。
PATH にそれらへのパスがあればよさそうだが、下述のように別の苦労に出くわした。
EMACSDATA=/share/emacs/24.4/etc
EMACSDOC=/share/emacs/24.4/etc ;; これもないと変数関数の説明が引いて来れない
EMACSLOADPATH=/share/emacs/site-lisp:/share/emacs/24.4/site-lisp:/share/emacs/24.4/lisp
EMACSPATH=/libexec/emacs/24.4/i686-pc-cygwin
としたところ、とりあえず error, warning なしで起動。
【番外編】
・なぜか invocation-directory の初期値が /usr/bin だった。
これを起点にいろいろ設定してるから、強引に .emacs (init.el) で /bin に再設定。
・これまで .emacs (init.el) での Windows バイナリベースの設定が、 Mew や YaTeX も含め、cygwin バイナリでことごとく破綻。
修正しきれず、あきらめモードである。。。
おとなしくコンパイル環境作って NTEmacs + IME パッチ を 32bit 環境の mingw でコンパイルするなり
そのまんま gnupack の cygwin 環境残すなりしたらいいんじゃないのかなあ
超ニッチすぎる
ここへの のような お前に言われんでも といった程度のカキコミ（ツッコミ）
入れてくるやつの心理・意義こそが到底量りしえない と 時々思う
ソース見ると cygwin-mount-substitute-longest-mount-name 内で "/[なんか]" のパターンは展開しないようになっていた
[] ってディレクトリ名で何か特別な使われ方してたっけ？
昔の TRAMP が /[hoge@hage]/huga みたいな構文だったんだけどそれ対策なんだろうか
がかけられるようになったと聞いたのですが、自分でビルドした Emacs 24.4
だと、
1. 同じファイルを、複数起動した Emacs で編集しようとすると「〜 locked
by ユーザー名〜」ってな感じでちゃんと動いているみたいなのですが、
2. 同じファイルを、Emacs とメモ帳で編集すると今までと同じ動作になりま
す。(メモ帳はロックファイルをまったく気にせず、Emacsはセーブ時に変
更されていることに気づく)
3. また、Emacs が作成するロックファイル(ドット+シャープ+ファイル名)は
エクスプローラで削除することができます。(Windows がロックしてるんじゃ
ないの?)
になるのですが、これで「Windows APIによるファイルロック」が正しく動作
してると言えますか? (自分ビルドが失敗してるのカモと思ったりしてます)
このスレで？
Emacs 同士でしかロック出来ないよ、って話は見つかるが API でロックなんてのは出てきてないような。
xyzzy のとごっちゃになってない？
この動作でいいんですね。安心しました。
どのみちEmacs外で変更されてた場合はセーブ時に警告が出るから
セーブを止めて.bakを付けるなり別名で保存した後、ediffで
元ファイルと比較しつつマージするのが通常の流れ
しかし相手が糞エディタだった場合はEmacsでの変更が上書きされる可能性は否定できない
subversion あたりでいいから vc 導入でいいような。
メジャーなエディタなら対応してるの多いし、ロックもしたけりゃできるし。
っつーか fopen() でロックするのはやめてほしいぞ > Windows
C-xC-b(list-buffers)の挙動が変かも…?
カーソルのある側のバッファに表示されたり、そうじゃない方に表示されりする。
対策方法あればご教示頂きたく。orz
ダウンロードして C-x 2 してから C-x C-b したりそのまま C-x C-b したりしてみたけど
再現できなかった。
例えば・・・
DOS窓で インストールしてあるところに行って(C:\NTEmacs24\bin)
> emacs.exe -q
1.起動した ntemacs24 で C-xC-b → C-xoで *Buffer List*側にカーソル移動。
2.そこの *scratch* をの行で enterして *scrattch*を開く。
3.ここで C-xC-bすると *scratch*側で *Buffer List*が開く。
4.今までだと最初に開いていた *GNU Emacs*側で *Buffer List*が開く。
ただ、ずーっとそうではない。今まで同様 *scratch* 側で C-xC-bしても
もう一方のバッファに開く様になっている場合もある。
・・・と言った感じですが・・・
C-x 4 C-o (display-buffer) の挙動だね
C-x 4 C-o使って色々バッファを切り替えてると同じ挙動になる
Help見ると挙動をカスタマイズできるようなんで変更してみればいいと思う
list-buffersはdisplay-buffer使ってバッファ切り替えてるから
display-bufferをカスタマイズすればlist-buffersの方も反映される
一応補足
やっ、やってみます。orz
こちらでも再現できました。
display-buffer-fallback-action の設定変更が原因みたいです。
24.4 では上記の変数に display-buffer-in-previous-window が追加されてて、
前回表示したウィンドウがあればそっちに表示するって挙動になるみたい。
以下で 24.3 と同じ挙動になると思います。copy-sequence しないと readonly な変数を modify するなって怒られる・・・
(setq display-buffer-fallback-action
(list (delq 'display-buffer-in-previous-window
(copy-sequence (car display-buffer-fallback-action)))))
カスタマイズするなら display-buffer-overriding-action の方がいいんじゃないか？
カスタマイズするなら display-buffer-overriding-action の方がいいんじゃないか？
ありがとうございます、助かります。orz
気持ち良くなりました。
どういう状態を表すインジケーターなの？
"[|]"と"[O]"がトグル以外の"-"の状態を見てみたくて、
M-x toggle-input-methodとか、半角/全角キーを押してるんだけど、
それとは別操作のこと？
(w32-ime-mode-line-update)
なるほどー。
IMEパッチをあてて
msys2で
./configure --without-all
make bootstrap && make install
やったけどIMEが有効にならない
なぜですか？
OSはWindows 8.1 64bitです
default-input-method を W32-IME にするとかなんかあった記憶がある
ttps://github.com/chuntaro/NTEmacs64/issues/3 ためしてみます
コントロールパネル→入力方法の変更→アプリウインドウごとに異なる入力方法を設定する
にチェック入れてるなら外してみるとか
Does Emacs support W32-IME? no
を発見しました
再configureします
いれてみたけどだめでした
どうすればよいのでしょうか
ならほかのパラメタをつけることで連鎖的にyesになるということだな！
ほおそれはなんだね？？？！！？？
...スレをよごしてしまってごめんなさい
ttp://d.hatena.ne.jp/j0hn/20070731/1185838981 ↑こちらのフォントの設定あたりを参考にやってみたのですが、
Warning (initialization): An error occurred while loading `c:/hoge/.emacs.d/init.el':
Symbol's function definition is void: w32-find-bdf-fonts
と言われてしまいます。orz
どなたか ntemacs24.4で intlfonts使えてる方みえますか?
そんじゃお言葉に甘えて↓
(setq bdf-directory-list
'("c:/NTEmacs24/intlfonts-121/Asian"
"c:/NTEmacs24/intlfonts-121/Chinese"
"c:/NTEmacs24/intlfonts-121/Chinese.BIG"
"c:/NTEmacs24/intlfonts-121/Chinese.X"
"c:/NTEmacs24/intlfonts-121/Ethiopic"
"c:/NTEmacs24/intlfonts-121/European"
"c:/NTEmacs24/intlfonts-121/European.BIG"
"c:/NTEmacs24/intlfonts-121/Japanese"
"c:/NTEmacs24/intlfonts-121/Japanese.BIG"
"c:/NTEmacs24/intlfonts-121/Japanese.X"
"c:/NTEmacs24/intlfonts-121/Korean.X"
"c:/NTEmacs24/intlfonts-121/Misc"))
(setq w32-bdf-filename-alist
(w32-find-bdf-fonts bdf-directory-list))
(create-fontset-from-fontset-spec
"-*-fixed-Medium-r-Normal-*-16-*-*-*-c-*-fontset-bdf,
ascii:-ETL-Fixed-Medium-R-Normal--16-160-72-72-C-80-ISO8859-1,
latin-iso8859-2:-*-Fixed-*-r-*-*-16-*-*-*-c-*-iso8859-2,
latin-iso8859-3:-*-Fixed-*-r-*-*-16-*-*-*-c-*-iso8859-3,
latin-iso8859-4:-*-Fixed-*-r-*-*-16-*-*-*-c-*-iso8859-4,
やっぱ本文が長いって怒られた^^;
分割するよ。
greek-iso8859-7:-*-Fixed-*-r-*-*-16-*-*-*-c-*-iso8859-7,
latin-iso8859-9:-*-Fixed-*-r-*-*-16-*-*-*-c-*-iso8859-9,
mule-unicode-0100-24ff:-Efont-Biwidth-Medium-R-Normal--16-160-75-75-P-80-ISO10646-1,
mule-unicode-2500-33ff:-Efont-Biwidth-Medium-R-Normal--16-160-75-75-P-80-ISO10646-1,
mule-unicode-e000-ffff:-Efont-Biwidth-Medium-R-Normal--16-160-75-75-P-80-ISO10646-1,
japanese-jisx0208:-JIS-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISX0208.1983-0,
japanese-jisx0208-1978:-Misc-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISC6226.1978-0,
japanese-jisx0212:-Misc-Fixed-Medium-R-Normal--16-150-75-75-C-160-JISX0212.1990-0,
latin-jisx0201:-*-*-medium-r-normal-*-16-*-*-*-c-*-jisx0201*-*,
katakana-jisx0201:-Sony-Fixed-Medium-R-Normal--16-120-100-100-C-80-JISX0201.1976-0,
thai-tis620:-Misc-Fixed-Medium-R-Normal--24-240-72-72-C-120-TIS620.2529-1,
lao:-Misc-Fixed-Medium-R-Normal--24-240-72-72-C-120-MuleLao-1,
tibetan:-TibMdXA-fixed-medium-r-normal--16-160-72-72-m-160-MuleTibetan-0,
tibetan-1-column:-TibMdXA-fixed-medium-r-normal--16-160-72-72-m-80-MuleTibetan-1,
korean-ksc5601:-Daewoo-Mincho-Medium-R-Normal--16-120-100-100-C-160-KSC5601.1987-0,
chinese-gb2312:-ISAS-Fangsong ti-Medium-R-Normal--16-160-72-72-c-160-GB2312.1980-0,
chinese-cns11643-1:-HKU-Fixed-Medium-R-Normal--16-160-72-72-C-160-CNS11643.1992.1-0,
chinese-big5-1:-ETen-Fixed-Medium-R-Normal--16-150-75-75-C-160-Big5.ETen-0,
chinese-big5-2:-ETen-Fixed-Medium-R-Normal--16-150-75-75-C-160-Big5.ETen-0
" t)
(append '(
("JISX0208" (japanese-jisx0208 . 0))
("JISX0212" (japanese-jisx0212 . 0))
("CNS11643.1992.1-0" (chinese-cns11643-1 . 0))
("GB2312" (chinese-gb2312 . 0))
("KSC5601" (korean-ksc5601 . 0))
("VISCII" (vietnamese-viscii-lower . 0))
("MuleArabic-0" (arabic-digit . 0))
("MuleArabic-1" (arabic-1-column . 0))
("MuleArabic-2" (arabic-2-column . 0))
("muleindian-1" (indian-1-column . 0))
("muleindian-2" (indian-2-column . 0))
("MuleTibetan-0" (tibetan . 0))
("MuleTibetan-1" (tibetan-1-column . 0))
) font-encoding-alist))
(setq default-frame-alist
(append
'((font . "fontset-bdf"))
default-frame-alist))
↑ってのを ~/.emacs.d/init.el に記載してます。
windows では 23.1 の時点で BDF フォントはサポート外になったよ。
etc 以下の NEWS.23 ファイルで BDF で検索してみるといい。
w32-bdf-filename-alist が残ってるのは消し忘れだと思う。
bdf2ttf とか使うしかないんでないかなあ。
まぁ別に BDFに拘っている訳では無いんだが…
ようは、フォントを windowsに頼らず emacs側に持たせたいだけなんだけどね。
仕事の都合で、海外の windowsマシン(もちろん日本語じゃない)を使う事が多いんよ。
で、USBで ntemacsを持ち歩けないかなぁと思って。
その場合、windows側のフォントに頼ってるとそれも面倒そうなので、いっそ emacs側(USB)に搭載できないかと思ってね。
あんがと、ttfでもちょっと調べてみるよ。
gnupack の emacs のランチャーは ttf をシステムに登録しないで
起動中だけ使うプライベートフォントとして登録する機能があるから
そっちを流用するのもありかと思う。
最新のだと cygwin emacs 向けになってるけど一個前のバージョンのを emacs だけ差し替えて使うのはありかなと。
USER\AppData\roaming\c:\homeが見つかりませんとなってしまいます。
デフォルトが頭に付いてるみたいなんだけど、直し方教えて
> windows では 23.1 の時点で BDF フォントはサポート外になったよ。
windows 上 24.3 や 24.4 でも、ps-multibyte-buffer を bdf-font-except-latin にして
ps-print-region とかが依然できてる、というのとは、また別の話？
※ps-multibyte-buffer を bdf-font にするとなぜか bdf-get-bitmap 関数が
Wrong type argument: number-or-marker-p, nil 吐くようになっちゃってる
それは ps-print がサポートしてるだけだよ。elisp 内で bdf ファイルをビットマップにして
ps に変換してる。
windows でサポートやめたのは表示用フォントとして直接 bdf フォントを読み込む方ね。
ttp://www.ksksys.com これはつまり (IME等パッチの当たっていない) オリジナルソースからのビルドってことね
落してREADME見たけど適用されているらしい
バイナリにはどんなプログラムをインストールしてるかが分かるPATHの内容と
ビルドした時のユーザー名が含まれるから一応気を付けた方がいいよ
どうやってチェックするの？
