
Ubuntu日本語フォーラム

ログインしていません。
テキスト編集にEmacs(GUI版)を使用しているのですが、おそらくUbuntu16.04にアップグレードしてから、ある条件でfcitxによる日本語入力が出来ないことがあります。
条件の一つとして、Nautilus(アプリ名 ファイル)からテキストファイルをEmacsで開いた場合でこの症状が出ます。
Mozcへの切り替えが出来ないだけではなく、fcitxからの入力自体を受け付けいていないようです。fcitxで仮想キーボードを表示してもそこからの入力は受け付けませんでした。
ただまったくfcitxが使えないのではありません。ターミナルからコマンドによりEmacsでテキストファイルを開くと普通に使えました。またUnityのランチャーからEmacsを立ち上げた場合も使えました(アプリ単独で起動)。
調べた範囲でfcitxが[使えない]、[使える]条件をまとめました。
[使えない]
- NautilusからEmacsでテキストファイルを開く
- DashからEmacsでテキストファイルを開く
[使える]
- ターミナルからEmacsを起動する(テキストファイル指定するしないに関わらず)
- UnityのランチャーからEmacsを開く(アプリ単独)
- DashからEmacs開く(アプリ単独)
- PCManFM(ファイルマネージャー)からEmacsでテキストファイルを開く
Emacsにはいろいろ設定してるので、仮想マシン上にクリーンインストールしたUbuntu16.04で設定していないEmacsで試しましたが同じような症状でした。同じように仮想マシンでUbuntu15.10を使って試した場合は症状は出なかったので16.04からの症状だと思います。
またgeditやLibreOffice WriterではNautilusで開いても通常通りにfcitxが使えます。
一応、回避策はあるわけですが出来ればいままで通りにNautilusからテキストファイルを開きたいと思うので、原因や解決策を見つけたいと思っています。
NautilusやDashなどからアプリを開く場合の挙動に原因があるのかと思うのですが…。
よろしくお願いします。
[テスト環境]
Ubuntu16.04 (64bit版)
Emacs 24.5.1 (GUI版)
fcitx 4.2.9.1
ファイル 3.14.3 (Nautilus)
オフライン
Emacsから、直接、mozc を使うパッケージがありますので、そちらを使ったらいかがでしょうか。
(emacs-mozc Ctrl+\(バックスラッシュ) で mozc 起動)
参照: http://compress.hatenadiary.com/entry/2014/02/24/001932
オフライン
提案ありがとうございます。emacs-mozc(mozc.el)自体は使ったことはあるのですが、
- 他のアプリと変換候補の見た目が異なる
- 日本語入力切り替えのキーをemacsでは別に慣れる必要がある
という2点が自分には馴染まなかったのでfcitx経由での入力を使ってます。emacsではfcitxだとインライン入力が出来ないなど満足してない部分もありますが、見た目と操作の統一感から今の方式を選んでいます。
そのような理由のためNautilus側をどうにかすることで解決したいと思っています。16.04以前では問題なかったので、なんとかなりそうとは思っているのですが…。
オフライン
fcitxではなくIBusを使うと報告した症状は起こりませんでした。なので回避策としてIBusを使うのも候補になりそうです。
ただ数年ぶりにIBusを使ってみましたが若干使い難いと感じたので(このへんとか)、もう少しfcitxの使用を前提にした解決策を探してみます。
IBusでは問題なかったので、Nautilusだけでなくfcitx側にも何か原因があるのかも知れません。
また仮想マシンでUbuntu16.04(症状あり)と15.10(症状なし)で
$ printenv | grep fcitx
でfcitx関連の環境変数を比べて見ましたが、コマンドの出力は一緒で変わってはいませんでした。
オフライン
起動しているプロセスの環境変数を確認してみるとどんな感じですか。
strings /proc/emacsのPID/environ
それと、
gvfs-open ファイル xdg-open ファイル
で開いた場合はどうでしょう。
(手がかりになりそうでしょうか?)
オフライン
アドバイスありがとうございます。おかげである程度問題点の絞り込みと、対策方法が見えてきた気がします(まだ解決はしてないです…)。
strings /proc/emacsのPID/environ
だと、nautilusで開いた場合とターミナルから開いた場合では明確に違いがありました。
nautilusからテキストファイルを開いたemacsの環境変数を調べると、Ubuntu16.04(日本語Remix、仮想マシン)ではfcitxを使用しているのに以下のようなibusに関する環境変数が出てきました。(Ubuntuはクリーンインストールでemacsもインストールしたまま設定せずに使用。またibusに切り替える操作もしていません)
XMODIFIERS=@im=ibus QT_IM_MODULE=ibus
一方同じ環境でターミナルから開いた場合も同様に調べるとそれらの項目はfcitxが指定されていました。
また症状が出ないUbuntu15.10では、nautilusから開いたemacsでもそこはibusではなくfcitxが指定されていました。
確認のため以下のように環境変数を指定してemacsをターミナルから開くと、nautilusでテキストファイルを開いた時と同じ症状となりました。(QTの方の環境変数はibusでもfcitxでも変化はありませんでした)
$ env XMODIFIERS=@im=ibus emacs
では、なぜnautilusで開いた場合はこのような環境変数が指定されてしまうのでしょうか?おそらくnautilusで開く場合とターミナルから開く場合では環境変数の読み込み方が違うのが原因なのでは?と思います。
以下のページではdbusやsystemdを使っている(?)アプリでは別の方式で環境変数を読むと書かれています。
https://wiki.archlinuxjp.org/index.php/ … 9%E6%95%B0
アプリの例にnautilusの名前も書かれているので、おそらくこのへんが原因なのではと思います。ちょっと調べただけだと、systemdなどの環境変数を変更する方法が分からなかったので確認できたわけではないですが。
解決方法の道筋は見えてきたのですが、自分の能力的に検証するには時間がかかりそうです。
以上を踏まえて、いま考えている回避策としてはnautilusから呼び出すemacsに
XMODIFIERS=@im=fcitx
の環境変数を渡して起動できればいいのではと思っています。これも少し時間がかかりそうなので、進展があってからまた報告します。
---
ターミナルからgvfs-open、xdg-open、mimeopen、gnome-openからemacsによりテキストファイルを開いた場合は症状は出ませんでした。
オフライン
結論 → 個人的には満足する結果が得られました
nautilusから起動するemacsに環境変数渡すって方法で以外にあっさり出来てうまくいきました。
nautilusから環境変数を渡されるタイミング次第で失敗するかと思いましたけど、思った通りにいって良かったです。
Ubuntuのデスクトップアプリとしてカスタマイズしたアプリを登録する方法に関しては以下のページを参考にしました。
http://lambdalisue.hatenablog.com/entry … /28/015515
すでにシステムにあるemacs24.desktopを探してきて(クリーンインストールのUbuntu16.04だとファイル名が違う)、手元にコピーして上記のページを参考に編集しました。
編集したところだけ記述すると
Name=GNU Emacs 24 (env) Exec=env XMODIFIERS=@im=fcitx /usr/bin/emacs24 %F
のようにしました。名前は環境変数を変更してるって意味でenvを入れ、環境変数のところでfcitxを指定しています。あとは .local/share/applications 以下に置いていったんログアウトするなりして設定を有効にしてやると、このカスタマイズしたemacsがメニューから選択できるようになります。これでnautilusからテキストファイルを開いてもemacsではfcitxが有効となり日本語入力が可能となりました(ちゃんとカスタマイズしたemacsに関連付けを変更する必要あり)。
(またクリーンインストールしたUbuntu16.04ではアイコンの指定がうまくいかなかったりするので、もう少しdesktopファイルを調整する必要あり)
strings /proc/emacsのPID/environ
でnautilusから起動したemacsについて確認してもちゃんと指定した部分の環境変数はfcitxに置き換わっていました。
根本的にはnautilus側(dbusやsystemd?)あたりを直さないとダメなんでしょうけど、なかなかそこまで手は回らないので個人的にはこの回避策で使っていきたいと思います。
オフライン
とりあえず原因はわかりました。
gnome-session-binaryがXMODIFIERSを「@im=ibus」に(ついでに「QT_IM_MODULE=ibus」に)固定させてしまっているというのが、あちこちに影響してしまっているようです。
(何気に、起動方法で挙動が変わってしまうDashのほうも問題ではありますかね)
とりあえず、次善策はyutarineさんの#7くらいでしょうか。
オフライン
https://github.com/GNOME/gnome-session/commit/39f146e6c5727105a3c88c2290654c6ef83102c5
のようですね。
おそらく簡単に直ると思われるので、バグ報告してみるといいのではないでしょうか。
オフライン
すみません。普段バグ報告はほとんどしたことがなく、どこにバグ報告すればいいのか分からずすっかり放置していました。
英語でここまでの経緯を書くのはちょっとむずかしいので、とりあえず
BugReport - Ubuntu Japanese Wiki
にあるように
Ubuntu Japanese Kaizen Project in Launchpad
の方に経緯をまとめて報告してみることにします。
オフライン
あらためて確認してみたところ、バグ報告もパッチもすでにありました。
Don't set ibus variables from gnome-session
とはいえ、日本語でバグ報告を書いても誰かが英訳しないといけないことには変わりないので、積極的に英語でバグ報告していただけるとすごく助かります。ゆたりんさんなら楽勝だと思いますし、かなり適当でも何とかなります。私のバグ報告もそりゃひどいもんですよ。
オフライン
バグ報告だから問題点を見つけるに至った経緯や枝葉末節の部分は極力省いて要点のみ書けばいい感じですかね。
そのへんちょっと難しく考えすぎていたようです。
今回は他の方がバグ報告してるので、今後バグを見つけたらLaunchpadの他の報告などを参考にやってみようと思います。
自分は発信する方の英語力はさっぱりなので、場数を踏んで自分に出来る範囲でやっていきたいです。
困った時はまたみなさんに相談することになると思いますが、よろしくお願いします。
オフライン
今回の件をバグ報告しようとする場合、
1. XIMで入力するアプリケーション(具体的にはEmacs)でFcitxが使えない
2. gnome-session-binaryが誤った環境変数を出力している
3 .ワークアラウンドはこう
で通じると思います。あとはgnome-session-binaryがgnome-sessionソースパッケージからビルドされているので、これをAffects packageで指定できれば完璧ですが、そこまでできない場合は誰かにヘルプを求めてもいいのではないかと思います。
ちなみに英語を1行も書かないでそのバグに困っていることをアピールする場合は、launchpadのアカウントを取得して該当のバグ報告を開き、"Does this bug affect you?"を"Yes"にするといいでしょう。
オフライン
久しぶりに確認してみたら、この環境変数が固定されてしまっているバグは修正されたようです。
3.18.1.2-1ubuntu1.16.04.2 : gnome-session package : Ubuntu
Bug #1594681 “Don't override IM variables” : Bugs : gnome-session package : Ubuntu
手元の環境のUbuntu16.04.1 LTSでもいつの間にか修正されたバージョン(gnome-session 3.18.1.2-1ubuntu1.16.04.2)にアップデートされてました。
いくつか適当に確認したところ、回避策を使わなくてもfcitxでも問題なく入力できるようになってましたので、とりあえずは解決といったところでしょうか。
どうもみなさん、コメントで助言などをいただきありがとうございました。
オフライン