NTEmacs スレッド 5 [転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
WSL＋VcXsrvでEmacsを表示すると、カーソルの移動がやたらガタついて気になって常用出来ない WSL2でいいなら最初からVMでemacs使ってるでしょ >>593
VMのemacsからはWindowsのアプリ、起動できないからね 利点も欠点も両方ある以上、
自分の使い方で利点が欠点を上回ると自分で判断した人が使えばよくて
他人がとやかく言うものではないな
と言う事をここにいる人はみんな
エディタ論争で学んできたじゃないか 実際に使おうっていうんじゃなくて興味オンリーなんだけど
Windows Terminalで動かす方法はある? 何となく思い立って、Gitリポジトリのemacs-27ブランチをチェックアウトして、
ビルド&インストールしてみたけど、素のままだと当然IME使えなかった…orz。 ddskkを使えば解決
Emacs使いは全てをEmacsだけで解決すべし
日本語入力もしかり >>598
横だけど、ここmaster用のパッチまであるのがすごいな。
試しにGitリポジトリのmasterをチェックアウトして、
このパッチ当ててビルド&インストールしてみたけど、
masterでちゃんとIMEが使えるようになったわ。 でも正直、こういうパッチとか必要なくて、公式で配布されてるWindowsバイナリを使って
設定も何も必要ないか、せいぜいdefault-input-methodを設定するくらいで
それでIME使って入力出来るようになってほしいよなぁ
まあ、ここでそんなことを言っていても意味ないんだろうけど 公式バイナリは--with-modulesでコンパイルされているから、
>>587で紹介されてるw32-imeadvを使えばいいのでは いやそういうのも必要なくて、公式バイナリだけでIME使えるようになってほしい、って話でしょ
もっとも、昔はIMEパッチ無しでも未変換状態でインラインにならないのを我慢すれば使えてたのが、
今ではそもそもIME使えないようになってしまったから、状況はむしろ悪化してしまっているんだけど Emacs-26.3とEmacs-27.0.91の公式バイナリだけでIMEでの日本語入力はできてるが、
"IME使えないようになってしまった"ってそれより最近の話? mozc_emacs_helper.exe使うようになってから、公式バイナリで問題ない。WSLでも使える方法だし。 w32-imeadvがバイナリも一緒に置いてあれば…… そういえば公式バイナリのZIPアーカイブって、なんであんなにいろいろと入っているんだろう。
例えばPythonが丸ごと入っているっぽいんだけど、Pythonが無いと動かない機能とかあったりするの？ >>607
これなんだけどEmacsをdaemonで動かすとinit.elに記述したw32-imeadvのLispを
なぜか読み込んでくれないんだよね。
どうしたものか… emacs-develでのこのメールから始まるツリーで議論されてるな
https://lists.gnu.org/archive/html/emacs-devel/2019-04/msg00720.html
んで、この議論の後に通常のリリース手順に沿って作られたと思われる
emacs-27.0.91-x86_64.zipが小さいんで、Emacs-27では改善されると思うね w32-imeadvは連続して100回くらい変換してるとEmacs自体が激重になるバグがある
何かがリークしてると思われる >>609
daemonモードはinitial-frameがまだ作られていない状態で起動するから、
init.el実行中はwindow-systemはnilじゃなかったかな(うろ覚え)
lisp-w32-imeadvを変更しない前提なら、
after-make-frame-functionsあたりに、lisp-w32-imeadvをloadするhookを
足せばいいのでは >>610
じゃあ26が一番でかいってことになるのかな 通常版は215MBあったからな
しかしno-depsとほぼ別バージョンになってるのはもうしょうがないのか
windowsの標準ライブラリでは実装できないんだろうけど 今更な話なのかもしれないけど、IMEパッチを本家にマージする
みたいなことって、今まで誰もやってないの？
あるいは既に誰かがやったけど拒否された、とかだったりするの？ >614
その昔、パッチを管理してた頃、emacs-dev 投げたけど、無視だった。
マウスカーソルの場所に応じて変形させるパッチはすんなり採用されたけど、IMEに興味無さそうだったな。 IMEでのかな漢字変換を使ってないと課題がつかめないよな
キーストロークを全部書いて、いかに不便か/便利になるかを示しきれなかったとか? >>617
普段から2バイトや3バイトを1文字につかう言葉のことなんてネイティブイングリッシュな
奴らから見たら野蛮で下等ってことじゃないのかな。 そもそもWindowsのIMEって日本語環境特有のものなの？
例えば中国語ってどうやって入力するの？ >>620
確かに26.xの時はソースが公開されてから一週間以内に公式バイナリが
公開されていたのに対して、今回は時間が掛かっているみたいだけど
何か問題でも発生しているの？ pretest版の27.1バイナリは出てるよ
https://alpha.gnu.org/gnu/emacs/pretest/windows/emacs-27/
8/13には公開されてたけど、DLLが足りてないって話がbug-gnu-emacsやemacs-develに出て、
一度更新されたようだ もしかして公式Windowsビルドが遅いのって25.3の反省? emacs-27.1-x86_64-installer.exeなんてのがあるから
試しにダウンロードしてインストールしてみたんだけど
標準でC:\Program Files\Emacs\x86_64の下にインストールされるんだな
C:\Program Files\Emacsはさておくとしてもx86_64って何だよ ARM版Windows10が有るから、そこにx86-64版とARM版が共存出来る事を狙ってるのだろう じゃなかった、lispディレクトリはどこになるの? >>630
C:\Program Files\Emacs\x86_64が$(prefix)で、その下は以前と一緒
C:\Program Files\Emacs\x86_64\share\emacs\27.1\lispとか
C:\Program Files\Emacs\x86_64\share\emacs\site-lispとか 普通に考えると $(prefix) は C:\Program Files\Emacs にしておいて
$(exec_prefix) を C:\Program Files\Emacs\x86_64 にするだろうに 今x86なものをProgram Files (x86)の方にインストールさせてるくせにarmがメインになってもマイクロソフトはProgram Files (x64)作らんのですか……？ というか、例えARM版Windowsが普及したとしても、その上でx86版の
公式バイナリを動かしたいなんて要望が本当にあるんだろうか
ARM版Windowsが普及したらARM版の公式バイナリが出て
それで万事解決ってことになると思うんだけど CPUに依存するコードは多分無いはずだけど、それでもすんなりビルド出来るかは分からんよ
それにARM版はx86-64のコードもかなり速く動かせるようだから、x86-64版を使うのも有りだと思う >>633
作るも何もx86-64版のインストーラは例えARM上で動いていても、x86-64版で動いてると思ってるから、普通にProgram Files以下に入れてしまう
自分で選択し直す事も出来るだろうけど、誰もそんな面倒なことはしないだろう emacs-27.1-i686-installer.exe を32bit機で動かすと
C:\Program Files\Emacs\i686
に入るだろうという予想は当然として、64bit機ではどうだろう
C:\Program Files\Emacs\i686
C:\Program Files (x86)\Emacs\i686
なんか前者のような気がしてならない NTemacs 27.1 の ewwでURLを入力して閲覧しようとすると
package tls is duplicated
や
could not connection to 443
が出て閲覧できない。
PATH には C:\emacs-27.1-i686\bin を入れてるけど
(gnutls-available-p) が nilになる。
うーむわからん。 >>639
27.1の公式バイナリでM-x ewwでhttps://www.google.com/を
指定してみたけど、普通にアクセス出来ている
どのバイナリを使っているのか判らないけど
自前ビルドのバイナリなら、C:\emacs-27.1-i686\binに
libgnutls-30.dllが無いとかじゃないの >>638
ということはやっぱり x86_64 とか i686 を掘る意味がないな
一番複雑な ARM64 機だったとしても
ARM64 バイナリは C:\Program Files
ARM32 バイナリは C:\Program Files (arm)
x86 バイナリは C:\Program Files (x86)
x64 バイナリは確かまだ動かないから関係ない
にインストールされるから衝突しないよね つうか、そんなにProgram Filesのバリエーションを増やしたいのか… scoopのextra bucketにも来てた早速インストール
emacsとか開発系のツールは最近全部scoopだわ 27.1で以前と比べて半分のサイズになったとはいえ、
公式バイナリって本当にたくさんのファイルが含まれているよな
includeの下にCのヘッダファイルがたくさんあるんだけど
これって本当にEmacsの動作に必要なんだろうか 27.1の公式
orgモードで
<eﾀﾌﾞ
などを入力するとブロックテンプレート
#+BEGIN_EXAMPLE
#+END_EXAMPLE
が挿入される機能が動作しなくなったけど
ﾊﾞｲﾅﾘに含まれているOegの仕様が変わったんでしょうか？ >>645
https://orgmode.org/Changes_old.html にあるOrg 9.2の変更点にある、
Change in the structure template expansionを読むといいと思うよ
(Emacs 26.3付属はOrg 9.1.9、Emacs 27.1付属はOrg 9.3のようだ) ttps://github.com/mhatta/emacs-27-x86_64-win-ime
の27.1を使わせてもらってるけど、
26でもWindows10 1803などで発生していた
IMEをONにしても日本語が入力されない問題がWindows10 2004で起きるね
現象も回避策もこれと同じだった
ttps://github.com/chuntaro/NTEmacs64/issues/3 >>644
多分MSYS2のパッケージ単位で必要なものを選択しているんじゃないかな
例えばPNG画像を表示するためにはlibpng16-16.dllだけあれば十分なんだけど
MSYS2のmingw-w64-x86_64-libpngパッケージには画像形式変換のためのexeも
ヘッダファイルもmanページも含まれているから、それら全部が公式バイナリに
含まれている、と 26.3から27.1に上げたら2,3日に一回ぐらいハングアップしてたのが解消した気がする
Chocolatey 27.1でもハングアップしたので >>650 は取り消し。 >>650 は、shell bufferでパスワード入力するときに開かれたmini bufferが、閉じられずに放置されたまま長時間経過すると発症する気配がある。
きちんとmini bufferでパスワード入力するように心がけてからは再発しなくなった。 >>652
IMEパッチ版がたまにIME入力中に落ちる現象が
27.1でもどうしても直せないので
本家バイナリ+それに乗り換えたけど
落ちないみたいなので安心感がある
未確定時のフォント設定、モードラインやカーソル色の変更くらいの使い方だと
IMEパッチ版と機能的にも違いが見えない
ただ、IMEパッチ版は副作用なのか
なぜかフック系のキーカスタマイズツールが効くようになるので
マルチモニタのモニタ間移動をアサインしてたのだけど
それの代替が見付からないのが個人的には不便 >>654
落ちないなら乗り換えるかなぁ？
「フック系のキーカスタマイズツール」ってなに？ >>655
メッセージフックを利用してキーを置き換えるツールのこと
特にWH_KEYBOARD_LLというのを使うツール(yamyとかのどかとか)が
本家バイナリからはキーを横取りできなくて効かないんだけど
IMEパッチを当てるとなぜか効くようになる >>656
yamyとか面白そうなんで試してみた。
IMEパッチ当たってるEmacsでもyamyのキー置き換えが効かないのあるんだな。
mhattaが配布しているIMEパッチでは効いた。TANEが配布しているIMEパッチでは効かなかった。
何が違うんだか…。 >>657
使いこなすの速いな・・・
IMEパッチだけが理由の100%じゃなかったんだ
スレチだけどMac版EmacsもOSのショートカットキーよりも
Emacsの方が優先されるものがある
多分、独自のキーバインドを実現するために
GNUがかなり低レベルレイヤでキー入力をキャプチャする方針で作ってるのを
mhatta版ではパッチ当てのどこかで解除してるのだろうと思う >>652をinit.elに組み込んでるんだけどdaemonモードだとやっぱりw32-ime-initalizeを評価してくれなくて
emacsclientwでwindowを立ち上げたときに有効にならない。
仕方なくこんな関数をinit.elに定義してemacsclientw.exe -c -a "" -e "(tr-ime-open)"で
windowを立ち上げて有効にしている。
(defun tr-ime-open()
(interactive)
(tr-ime-advanced-install)
(w32-ime-initialize)
)
after-make-frame-functionsへw32-ime-initializeのadd-hookがどうしてもうまく行かなくて
どうやってel書いたらいいのかわからない。 >>659
俺は server-after-make-frame-hook に同じような設定してうまく行っているよ
tr-ime-open相当の関数で、モードラインの設定なんかもやっている
(setq w32-ime-init nil)
(defun tr-ime-open () ""
(when (not w32-ime-init)
(tr-ime-advanced-install)
(w32-ime-initialize)
(setq w32-ime-init t)
))
(add-hook 'server-after-make-frame-hook 'tr-ime-open) after-make-frame-functionsって、挙動を見た感じだと
実際にframeが表示され終わる前に呼ばれているような感じなんだよな https://github.com/K-Arakawa/emacs-ime-patch
ここのIMEパッチ、割と頻繁に更新されてたんだけど、ここ一ヶ月くらい更新が止まっている
少なくとも今のEmacsのgitリポジトリのmasterやemacs27ブランチにはうまく当たらない
Emacs 27に対応してるのってここぐらいだと思うんだけど
ここがこのまま更新止まっちゃったらどうしよう… >>664
導入コストや安定性を考えると、もはやそれ一択 NTEmacs自体は公式のインストーラーが有るからそれを使うべし >>664
最新のEmacsで動くか分からないけど、Google日本語入力と連携させるならこんなのもある
https://github.com/rzl24ozi/mozc-emacs-helper-module
これにmozc-popupとmozc-imパッケージ組み合わせるといい感じになる 27.2が出てビルドしてるんだけどconfigureで指定した
--prefixを無視しやがる。
おかげでmsys2の/mingw64以下へ問答無用で
インストールされる…
config.logを見ても勝手に--prefix=/mingw64に
変更されてるのがわかるし >>668だがconfigureのオプションに--no-createが混ざってた。
そらできんわ。
頭冷やしてくる。 27.2に上げてみたけど、27.1と比べて起動が速くなったような気がする
気のせいかな msys2のmingw64でコンパイラをclangにしたときのmakeができない。
FedoraだとできるのになぜWindowsのmsys2だとclangでmakeさせてくれないんだろう。
Makefileを見ているとコンパイラに渡すヘッダファイルのパスの内容がGCCのときと比べて
clangの場合、明らかに足りないのが気になるけど。 単純にMSYS2+Clangの組み合わせでのビルドがサポートされていないという話なのでは Fedora+Clangの組み合わせでビルドできたからMSYS2+Clangでも試してみたら駄目だった
というだけの話なのでは Windows版の公式ビルドが来たな。
しかしよりによって4月1日なのかよ。 MSYS2でユニバーサルCRT対応のバイナリをコンパイルできるようになったので
試してみたがcmdproxy.exeのビルドでコケる。
cmdproxy.cで" undefined reference to `_snprintf'"って出るんだけど
冒頭にexternで_snprintfが定義されているのになぜ…。 ライブラリのリンクに問題があって、当該関数が見つからない状態。 _snprintfの件、ちょっと気になったので調べてみたんだけど
/ucrt64/x86_64-w64-mingw32/include/stdio.hの776行目から795行目にかけて
'_UCRT'が定義されているときには_vsnprintfを使って_snprintfを
定義するようなコードがあった
なのでMSYS2のUCRT64のライブラリには_snprintfがないんだと思う
試しにcmdproxy.cに'#include <stdio.h>'を追加してみたんだけど
定義の重複が多発してコンパイル出来なかった >>681
そりゃcmdproxt.cに
stdio.hの内容をここにコピーしているからincludeしたくない
書いてあるからね。
でcmdproxy.cにstdio.hをincludeさせてソースの冒頭にある
printfとかのstdio.hからコピーした関数の定義や宣言を
コメントアウトしたらコンパイルが通るんだけど今度は
pbootstrapの生成がこける。 MSYS2にCLANG64の環境が追加されたので試しにEmacsをビルドしようと思ったら
必要なライブラリがCLANG64環境ではまだほとんど提供されてなかった
残念 NTEmacsからサブプロセスに引数渡すときcp932変換しないといけない問題。
Windows 10 1903以降なら実行ファイルのmanifest書き換えたらうまくいくんじゃねっていろいろ調べてたら
すでにtr-emacs-ime-moduleの作者さんが検証してた。
(https://gist.github.com/trueroad/d309d1931100634c2cd1058a0620c663)
msvcrt関連の不具合はあるもののこれでcp932の呪縛から解放された… >>684
いいねぇ
ucrtでビルドしてこれ組み合わせれば完璧だと思うけど、ucrtビルド成功したやついないの？ >>685
あれはソースコードを何か所か修正したら何とかなるという感じではなさそうだからねぇ
多分だけど、MSYS2のUCRT64環境とEmacsのWindow依存の部分を理解している人が
それなりに腰を落ち着けて対応する必要があるんじゃないかと >>686
ucrtのビルド失敗で気になるのがcmdproxy.cの冒頭の_snprintfとかの定義や宣言を無視するのが何故なのかってことなんだよな。
>>682でも触れてるけど。 少し前に話題になったnative compilationを試してみたんだけど
これビルド時だけじゃなくEmacsの実行時にもGCCが必要になるんだな
だとするとEmacs28でnative compilationがデフォルトで有効になった場合
Windows公式バイナリにGCCがまるごと含まれることになるから
27で減少した公式バイナリのサイズが28で激増することになりそう >>689
「パッケージ依存関係の追加」の意味がよく判らないけど、.el→.elnのコンパイルが
デフォルトではEmacsが初めてその.elをロードした時に行われるので、その際にGCCが必要になる
Emacs本体に含まれている.elについてはビルド時にまとめてネイティブコンパイルすることが出来るし
3rd Partyの.elについてもbatch-native-compileで明示的にネイティブコンパイルすることが出来るけど
後者についてはEmacs本体をインストールした後にEmacsを実行して行うのだから
いずれにしてもEmacsの実行時にGCCが必要になる 使ってるのはlibgccjitだよ
Emacsにリンクされてるはず
されてなければコンパイルなんてしない ■ このスレッドは過去ログ倉庫に格納されています
