>>750
ありがとうございます。
私の環境でフォントサイズに合わせて日本語と欧文の幅がぴったり2:1になるように微調整して、
同じファイルを表示しています。

私の最初の設定はDejavu Sans Mono/Migu 1Mでこの設定はMenlo/Noto Sans CJK JPなので、
Notoフォントの高さのせいで行間が広くなりますが、
日本語と欧文の文字の大きさの比率はほぼ同じだと思います。

face-font-rescale-alistは横幅だけでなくフォントを一定の比率で拡大するので、
それぞれのフォントサイズを直接指定した場合と同様、
拡大率に応じて日本語と欧文の文字の大きさのバランスが崩れてしまいます。

サイズを調整すると少し体裁よくなりましたが、
文字間が調整できず詰まってしまうのは仕方がありません。

emacs -nwだとターミナル側で最初から文字間が広く空いて調整もできるので、
詰めがゆったりして日本語と欧文のバランスもよく美しく見えます。
GUIのEmacsで同程度に調整できるといいんですが。

urxvt+Emacs

自前で文字間隔を直したフォントを作るって手はある。
すべてのアプリで使えるので最も汎用の解にはなる。

でもエディタ以外で必要かな？
エディタで使う等幅フォントは半角の欧文の詰めがどうしても見苦しいから、
バランスをとるために全角の文字間が余分に空いててほしい。
桁数とか気にしなければプロポーショナルでもいいけど。

Debianスレから誘導されてきました
Debianでstretchからbusterに上げたら
emacs（anthy）で日本語の一部が
入力とともにオンラインで化けるようになりました
化けるのは以下をはじめとした記号で日本語は化けません
（コロンの前の文字を入力すると右のように化けます）
（: 鐚\210
）: 鐚\211
ー: \343\203\274
？: 鐚\237

以下情報です
- emacs lucid 1:26.1+1-3.2
- 日本語はeuc-jpを使用
- (set-input-method "japanese-anthy")のみの.emacsで化けます
- .emacsがないと化けません
- libreofficeでanthyで入力しても化けません
anthy-elに原因がありそうなのですが直し方が分かる方いますか？

sjis, euc-jp は国際化されていないから、外人は知らない。
世界中で知っている人は、まずいない

日本人が、何百もある外国語のエンコードを、誰も知らないのと同じです

UTF-8 を使ってください！

かなり板違いだけどlocaleを変えたくないのであれば一度emacsをpurgeしてからapt install
それで駄目なら諦めてUTF-8にするかemacs-mozc等に乗り換えるしかない

>>757
>かなり板違いだけどlocaleを変えたくないのであれば一度emacsをpurgeしてからapt install
駄目ですね
困った困った

>>758
ならば繰り返しになるけどemacs-mozc等を試してみるか、諦めてlocaleをja_JP.UTF-8にするしかありませんな。
今時eucJPに拘る理由はよくわかりませんが。

>>759
emacs-mozcで直りました
今はこんなのあるんですね
まだまだeuc-jp生活が続きます

よく分かりませんが、
全体の locale は ja_JP.utf8 であってもよくて、
必要なファイルのみ euc-jp にしておけばいいんじゃないですかね。

localeでja_JP.UTF-8を作っといて
export LANG=ja_JP.UTF-8
し，中身が
(set-default-coding-systems 'utf-8)
(set-input-method "japanese-anthy")
のみの.emacsで起動したら>>755の症状です．
anthyに問題あるような...

-anthyに問題あるような...
+anthy-elに問題あるような...

>>761
ファイル名がeuc-jpでエンコードされたファイルがたくさんあるのです
ファイル名がutf8のファイルと混在するのでなかなか移行できない
diredでutf8とeuc-jpをキーひとつで切り替えて見られると随分良いんだけど
ないかなぁ？

unixで日本語ファイル名を抵抗なく使っている時点で運用を見直すべき。
個人の感想です。

nkf使えばええやんと思ってしまう

http://www.ice.is.kit.ac.jp/~umehara/misc/comp/20090423.html
こちらとか有用かと

.emacsという事はバイトコンパイルはしない派なのかな？
好き好きだけど

>>765
賛同はするけどデスクトップとして使うと
日本語ファイル名からは逃れられないよ

>>766,767
有難う御座います
これまでのファイル数が膨大なので
一括変換は躊躇いますな
diredでエンコードをキータイプ1つで
切り替えられればhappyなんだけど

utf8に変わったときにみんなそれやったんだよ。あなだけじゃない。解決策も対応も出揃ってるから後は好きにすればいい

file-name-coding-system を dired のバッファ単位で自動判別して設定するって
わりと簡単そうだし、どこかにパッチとかないのかな。
まあパス名に関しては混在はトラブルのもとなので、やるなら一気に全部変換した方がいいとは思うけど。

全面移行するまでの当面の間はIMだけUTF-8で動かして、
default-file-name-coding-system は euc-jp のままでいいんじゃない?

変換が怖いなら環境をクローンしてテストしてみればいい。
それすら面倒ならeuc-jpに固執し続ければいい。
それで不便じゃなければ。
とりまEmacsでの文字化け問題は解決したみたいですからな

>>770
http://www.google.com/search?q=dired+文字コード+切り替え

>>767
結局convmvで一括変換しました
pdumpfsで取ってきた15年分のバックアップを今から変換します

>>775
大変ですね。頑張って下さい。
最後に、望んだ手法かどうかに関わらず、お世話になった方にはその都度お礼を言ったほうが宜しいかと。
実はDebianスレから貴方を見てきましたが、誰に対しても一度もお礼の言葉がありませんね。
PCには頭を垂れなくても仕事しますけど、貴方が接してきたのは単なる文字情報ではなく人間なのですから。

>>776
全くないかと言えばそんなこともないと思うのですが...
会話のように書いてますので書面よりは少ないかもしれません
御忠告有難うございます
おかげさまでだいたい望み通りの環境になりました

むしろ、2ch（5ch）でお礼とか強要している方が感覚がズレてるだろ..
ここはfjじゃねえぞ。

所詮便所の落書きだからな

バキュームカーと勘違いしてんじゃねえのか

>>776
うわぁ

いちいちお礼なんかしてたらスレの
半分がお礼になるのではないだろうか。

報告は欲しくね？

報告は欲しい。
礼はいらん。(礼があっても構わんが)

礼はするが報告がないってパターンは割とイライラする。
礼とかどうでもいいから結果を書けよと。

俺って感情がないからお礼とか全然ありがたみ感じないんだよね。

>>769
たとえばUbuntuとかなら
LANG=C xdg-user-dirs-gtk-update
とか、しないの?

5chでお礼なんて要らないな
だけど上手く行ったかの報告は絶対必要
それさえ聞ければ十分

>>786
「日本語ファイル名からは逃れられないよ」の主な意味は
他人からメールに添付して送られてくるファイルが日本語ファイル名ってことです
私自身は基本的にはファイル名にascii文字しか使いませんが
他人から送られてくる日本語名のファイルをいちいちリネームする訳にはいきせん

>>788
なるほど。私はファイルシステムに取り込む時には体が自動的にリネームしてしまうのがで、そこまで考えが至りませんでした。失礼しました。
まあ、日本語ファイル名で何の問題もない世界に、いつかはなってほしいものです…

>>789
WSLでemacs使っていると、DrvFsにもアクセスするから普通に漢字ファイルにアクセスしますしね

妙な質問ですみませんが、Git for Windowsのgit.exeを、WSL1のemacs -nw上のMagitやeshellから使うことってできませんか？
理由は、WSL1のgitより数十倍速いからです。
WSL1でgit statusが20秒以上かかる巨大レポジトリでも、Git for Windowsだと一瞬で終わる。

しかしWSL1のbashでgit.exeを呼び出しても、あまり正常に動きません。
ましてWSL1のEmacs -nw上のeshellやshell-modeだと、全く何も表示されません。

MSYS2にGit for WindowsとEmacsをインストールすると正常に動きますが、今度はEmacs自体の挙動にいろいろ問題があって…。

以下は参考リンク

git bash for windows is based on MSys2. Why not just use Msys2 and it's git? : git
http://www.reddit.com/r/git/comments/ama1j0/git_bash_for_windows_is_based_on_msys2_why_not/

Install inside MSYS2 proper git-for-windows/git Wiki GitHub
http://github.com/git-for-windows/git/wiki/Install-inside-MSYS2-proper

【Windows/msys2】Emacs 26.2の64bit版をインストール | The modern stone age.
http://www.yokoweb.net/2019/06/18/msys2-emacs-26-2-install/

NTEmacs @ ウィキ - アットウィキ
http://w.atwiki.jp/ntemacs/
> 本サイトは NTEmacs の情報サイトなのですが、私が WSL版 emacs に乗り換えたため（略）…
> 今のところ、Windows で emacs を使うには WSL emacs on VcXsrv がベストな選択だと思っています。

>>791
shell-modeでexeコマンドが動かないのは、Windows 10 1809で埋め込まれたWSLのバグだと思います。
http://github.com/Microsoft/WSL/issues/3895
git.exe status | cat とすると表示すると思います。
git.exe "$@" | cat のようなシェルスクリプトを作ればOKと思います。
また、少なくともWindows 10 1809までは、VolFs上のディレクトリをカレントディレクトリ
としてexeコマンドを動かすことができません。
Windows 10 1903からはできるかもしれませんが、今手元にある環境が1809のため確認できません。
とりあえず、今分かる情報です。

>>792
丁寧なレス、ありがとうございます。ご返事が遅くなりましてごめんなさい。

まずこちらの状況に進展がありました。以下のページを参考に
Magit User Manual: Git Executable
http://magit.vc/manual/magit/Git-Executable.html

・~/.bashrcに export PATH=/mnt/c/tools/msys64/mingw64/bin/:$PATH
・~/.emacs.d/init.elに (setq magit-git-executable "git.exe")
と書くと、どうもMagitがGit for Windowsを利用して動いているようです。正直、自分でも驚きました。
shell-modeとすら連携できなかった git.exe がMagitと連携できるなんて。

M-x magit-version
Magit 20190817.1623, Git 2.23.0.windows.1, Emacs 25.2.2, gnu/linux

しかも、WSL1の素のbash上でも機能しないGit for Windowsの一部の機能が、Magit上では動いているように見えます。
例えば bash上で git.exe stash list を実行しても何も表示されないのですが、Magit上ではstashもちゃんと表示されている。不思議です。

とりあえず恐る恐る使ってみることにしますが、今のところSSHのGitレポジトリのpushやfetchができないですね。
これらの機能だけMSYS2のbash上で使うことにします。

----

貼っていただいたissueはまさに自分も悩んできたことで、大変ありがたかったです。
init.el に (setq process-connection-type nil) と書くことで、shell-modeでgit.exeが動作するようになりました。
ただeshellの対応法が載っていなかったのは残念です。

なお、自分の環境はWindows10 1903でして(May 2019 Updateを手動で入れました)、VolFs上(~ や /)でgit.exeが動作することも確認できました。
ただ自分はふだん、Windows版Eclipseとファイルを共有するため、WSL1でもDrvFs上でファイルを編集していて、VolFsはあまり使いません。

Emacs 26.3 released
http://lists.gnu.org/archive/html/emacs-devel/2019-08/msg00577.html

26.3ビルドしたお
今はdoom emacs使ってるけど快適だお

「GNU Emacs 26.3」リリース　2019年8月30日16:30　末岡洋子
http://mag.osdn.jp/19/08/30/163000

　テキストエディタGNU Emacs開発チームは8月28日、最新安定版となる「GNU Emacs 26.3」を
公開した。「令和」のサポートなどが加わったメンテナンスリリースとなる。

　EmacsはLispの方言であるEmacs Lispを中核にし、拡張性、カスタマイズ性などの特徴を備えた
テキストエディタ。Windows、macOS、GNU/Linuxなどさまざまなプラットフォームで動作する。

　Emacs 26.3は、2018年5月に公開されたEmacs 26系の最新版。メンテナンスがメインのリリースと
なる。

　コードポイントU+32FFが加わったUnicode Character Databaseをコンパイルすることで、新元号の
「令和」をサポートした。

　また、help-enable-completion-auto-loadオプションを導入、kろえを利用することでEmacs 26.1で
導入した新機能（C-h fとC-h vのコンパイル時にファイルを読み込む）を無効にできるという。そのほか、
GNU ELPAパッケージの署名チェックのための新しいGPG鍵も含まれている。

令和をサポートってなんだ？
日付の変換とかそういうこと？

考えにくいが、日本の年号変換の関数がが組みこみ？

㍼、㍻、㋿←これに対応したってことじゃないの

U+32FF を C-u C-x = したとき

name: SQUARE ERA NAME REIWA
general-category: So (Symbol, Other)
decomposition: (square 20196 21644) (square '令' '和')

っていう風に名前などが表示されるとか
同じく U+32FF に対して M-x ucs-normalize-NFKC-region で
令和
に変換されるとか