Powerline: Gnome3.22のサポート

Powerlineは何を表示するかを決定します。これを端末に正しく書き込むのは、tmuxの責任です。 あなたのスクリーンショットはどちらかがあるように見えます

1. tmuxは、端末が実際よりも1セル広いと誤って考えています。
2. tmuxが1セル幅であると見なし、端末エミュレーターが2セル幅であると見なす文字が1つあります。

Powerlineはこれでは何もできません。 別の文字セットを選択することで問題を回避できます（たとえば、 top_levelテーマをasciiか、問題のある文字を1つだけ見つけてオーバーライドします）が、これはtmuxのバグです。

@frolもGnomeにあるよう

urxvtで正常に動作します！

powerline.jsonの変更：

に

            "time": {
                    "before": " "
            },

@mrmodoloうん、これは役に立ちます！

@burningTyger testingリポジトリを使用しているので、同じ日にTmux2.3.1とGnome3.22を入手し、Tmuxの非互換性だと思ったのですが、間違っていたようです。

@mrmodolo時計の記号が原因ですが、他の記号は電力線フォントで使用できないため、前の文字列を空のままにして、今のところも解決します。 ありがとうございました。

私の設定では、「」はUTF8文字f017です。
シンボルはVIMで印刷できます。
挿入モードに変更します。
Ctrl + Vキーを押しながら、uf017と入力し

問題を引き起こす時計記号はどのUnicode文字ですか（前のコメントの黄色の背景のスクリーンショット）？

（注：U + F017は私用領域にあり、私のシステムではチルダ（〜）記号と同じように表示されますが、これはシステムで時計として表示されるものである可能性がありますか??もしそうなら、 @は何をしましたか

$ printf "％d \ n" \ '
8986
$ echo "obase = 16; 8986" | 紀元前
231A

VIMタイプの場合：
Ctrl + Vキーを押しながら、uf231Aと入力し

今私はこれを持っています！

Archを使用していますが、Ubuntuはデフォルトで電力線でを使用しています！

だから...私はそれを正しく理解していますか：

• U + 231Aでは正しく機能しませんが、
• 代わりに同じ位置にU + F017を使用すると、正しく機能しますか？

（またはその逆ですか？申し訳ありませんが、私はかなり迷っています。）

私の場合、同じ位置にあるU + F017で問題なく動作します！
私の設定ファイルは次のとおりです。

「時間」：{
「前」：「」
}、

gnome-terminalバグレポートを最初に読んだのは、bash / zshの電力線プロンプトが誤動作したと思います。 ここでスクリーンキャストを見ると、それは電力線のtmuxステータスバーであるように見えます。

誰かが私にtmuxを電力線に設定するために従うべき最短のドキュメントを教えてもらえますか（このバグを再現できるように）？ 私は電力線を使ったことがなく、tmuxにもほとんど慣れておらず、Googleはあまりにも多くの結果を出します。 この問題をデバッグできてうれしいですが、電力線のエコシステムに慣れる時間がありません。 前もって感謝します！

私はアーチを使用しています...
yaourt -S python-powerline

.tmux.confで...
run-shell "powerline-daemon -q"
ソース "/usr/lib/python3.5/site-packages/powerline/bindings/tmux/powerline.conf"

tmuxがU + 231Aの方が広いと考えている場合、GNOMEターミナルは問題があると考えます。問題は、電力線がなくても完全に再現できるはずです。 status-オプションにこの記号を含めるだけです（注：かどうかはわかりません）。 tmuxが使用するレンダリングの最適化。 status-rightは何かが含まれている必要があります）。

情報のおかげで！

私はUbuntuYakkety（gtk + gnome 3.20 / glib 2.50.0 [gnome3.22に属する] / glibc 2.24）を使用しており、tmux-2.3とgnome-terminal / vtegitを手動でコンパイルしています。 このバグを再現することはできません（電力線でも、単純なステータスでも）。

U + 231Aの方が広いとtmuxが考えることに問題がある場合、GNOMEターミナルは

これは現在の問題を説明しません。 次に、tmuxは1文字少なく（幅が広いと見なすため）、幅全体を埋めることはありません。 逆だと思います。tmuxは通常の文字だと考えていますが、gnome-terminalは2倍の幅だと考えています。 したがって、それはオーバーフローします。

https://bugzilla.gnome.org/show_bug.cgi?id=762052#c30で述べられているように、gnome-terminal（vte）はwcwidth（）の代わりにg_unichar_iswide（）を使用します（これはxtermおよびおそらくtmuxでも使用されます） 。

これらを試していただけませんか：

echo $'\u231A' | wc -L

これはglibcのwcwidth（）を出力します。出力は1になると思います。

echo ABCDE; echo a$'\u231A'cde

大文字と小文字は正しく整列していますか？ xtermではそうなると思いますが、gnome-terminalではそうではありません（時計は2つのセルを占有します）。

glibとglibcのバージョンを共有していただけませんか？ 私の大げさな推測では、変更ログに「UnicodeサポートをUnicode 9.0.0に更新」と記載されているglib2.50.1があり、Unicode9.0.0によってこのコードポイントの幅が増えた可能性があります。

私の大げさな推測は本当だったようです：

ftp://ftp.unicode.org/Public/8.0.0/ucd/EastAsianWidth.txt

2313..231F;N     # So    [13] SEGMENT..BOTTOM RIGHT CORNER

ftp://ftp.unicode.org/Public/9.0.0/ucd/EastAsianWidth.txt

2313..2319;N     # So     [7] SEGMENT..TURNED NOT SIGN
231A..231B;W     # So     [2] WATCH..HOURGLASS
231C..231F;N     # So     [4] TOP LEFT CORNER..BOTTOM RIGHT CORNER

時計と砂時計のコードポイント（およびおそらくそれ以上）は、Unicode9.0.0によって広くなりました。

gnome-terminalは、glib 2.50.1以降で実行されている場合、新しい幅を使用しますが、xtermとtmuxは、最新リリース（2.24）がまだ古い幅を使用しているglibcに依存しています。

ここにリンクされているgnome-terminalバグレポートが見つからないので、参照用にここにあります。
https://bugzilla.gnome.org/show_bug.cgi?id=772812
https://bugzilla.gnome.org/show_bug.cgi?id=772890

大文字と小文字は正しく整列していますか？ xtermではそうなると思いますが、gnome-terminalではそうではありません（時計は2つのセルを占有します）。

このシンボルには別の問題が発生する可能性があります。konsoleとtmuxはどちらも1セル幅だと考えていますが、フォントレンダリングライブラリはその表示セルに拡大縮小するように指示されていません（実際のグリフは終端にこのグリフがないため、別のフォント）、次のような結果になります

。 これは、ここの人々が経験している問題につながることはありませんが、これにより、テストで誤った結果が得られる可能性があります。

konsoleは、私が知っている唯一のエミュレーターであり、セルに整列しないというこの狂気を実行します。

他のすべてのエミュレーターでは、ウォッチシンボルがcのセルにオーバーフローする可能性がありますが、文字は互いに正確に下になります：Cc、Dd、Ee、または（glib-2.50のgnome-terminalで予想されるように） .1）DcとEdが整列します。

私は、Arch x86 + tmuxで、Termiteでも同じ問題を抱えています。 ただし、themes /powerline.jsonの時計アイコンを編集しても何も変わりません。

本日、Debian Stretch（テスト）に登場しました。 LXDEとTildaを使用しています。
tmuxバージョン2-3-1
tildaバージョン1.3.1-1 + b1

どのglib / glibcパッケージに興味があるのか​​本当にわからないので、スクリーンショットを作成しました。

更新：これは_Liberation Mono for Powerline_フォントですが、_Linux Libertine Mono_からの出力は同じです（他のフォントも同じだと思います）。

編集：時計アイコン（U + 231AまたはU + F017）の編集も私には機能しません。 助言がありますか？
Edit2：私のスクリーンショットでは、 wc -l代わりにwc -L wc -lを間違えて使用しましたが、この例では出力は同じです。 1.1。
Edit3：最後に、tmux + powerlineが再び機能します、ありがとうございます！ から時計記号を削除しました/ usr / local / lib / ...、上記およびからのユーザーのローカルファイル
~/.local/lib/python2.7/site-packages/powerline/config_files/themes/powerline.json
再起動後、それは魅力のように機能します。

@ dunemkk 、/ usr / local / libの時計のサインを削除するとはどういう意味ですか？

@ s0r00t私の悪い。 コメントを更新しました。
今、私はこの場所がまったく言及されていなかったことがわかります。

最初は、ユーザーのディレクトリにpowerline.jsonファイルがあることすら知りませんでした。 ファイルが入っていることがわかりました
/usr/local/lib/python2.7/dist-packages/powerline/config_files/themes/powerline.json
（zsh / tmux / vimに同様のロケーションバインディング電力線を使用したため）、システム内のどこかにあるかどうかをわざわざチェックしませんでした。 おそらくこれが機能しなかった理由です。 ; P

ahaaslerのコミットは私を助けました： https ：

おかげで、私はそれを修正しました。

チャームのように働いた。
参考：後ろに2つのスペースがある

他の可能な、しかしテストされていない文字は次のとおりです。
U + 23F0 （目覚まし時計）
U + 1F570 （マントルピース時計）
U + 1F570からU + 1F567 （時計の文字盤）

回避策をありがとう！

これはまだ問題があるため、プロファイルがUnicodeバージョン9の文字幅を使用するように設定されている場合、新しいバージョンのiTerm2のOS X / macOSユーザーがこの問題に遭遇する可能性があります-ここでの回避策は、[設定]-> [プロファイル]のチェックボックスをオフにすることです。 ->テキスト-> Unicode。

この問題がubuntu16.10で突然発生しました-先週、これは発生しませんでした。 変だ。 おそらく、apt-getアップデートまたはpipアップグレード中に何かが変更されたので、覚えていないでください。

それで、公式の修正は何ですか？

@binarykitchen昨日からここでも同じです！

解決策を見つけました

cp /usr/share/powerline/config_files/themes/powerline.json〜/.config/powerline/themes/

次に、〜/ .config / powerline / themes / powerline.jsonを編集して、次のようなブロックを見つけます。

                "time": {
                        "before": "  "
                },

「before」の値を「◴」に置き換えました

@CVirusに感謝しますが、私の場合、すでにそのウォッチ文字がありました。

しかし、.configフォルダーにjsonファイルがありませんでした...それが原因でしょうか？

そして、このスレッドの上のいくつかのコメントは、時計の文字を削除または交換することを言っています。 混乱しています。

@binarykitchenは、お持ちの時計を私が貼り付けた時計または他の文字に置き換えます

@CVirusは実行します-明確にするために、文字を置き換えた後に何かを再起動する必要がありますか？ 私のマシン、zshセッション？

明確にするために、それは私のリモートサーバーへのtmuxセッション中にのみ発生します。 そして、私はサーバー側ではなく、クライアント側でそのjsonを修正しているだけです。

お知らせ下さい ...

@binarykitchen powerlineが存在するプロセスを再起動する必要があります。おそらくこれはpowerline-daemonを意味しますが、shellやtmuxは意味しません。 ここではzshは特別ですが、zpythonがインストールされている場合、powerlineはシェルプロセス内に存在します。 zpythonを自分でインストールしない限り、これが発生する可能性はほとんどありません。

@ ZyX-ありがとうございます-zpythonがインストールされているかどうかはわかりませんが、pipではなくapt-getを介してpowerlineをインストールしました。

最後の質問です。「リモートサーバーへのtmuxセッション中にのみ発生します」-電力線の問題がクライアント側にあるのかサーバー側にあるのかを確認するにはどうすればよいですか？

@binarykitchenどのアプリケーションが電力線を使用する

@ ZyX-I「どのアプリケーションが電力線を使用する場合でも、実行されている側で電力線を使用します。」

->私の問題は、tmuxでsshセッションを実行すると、サーバー側の電力線のインストールに問題があると思い始めたことです。 しかし、私が電力線についてもっと読むと、それはクライアント側の問題だと思います。 それは本当に抽象的なです...

マシンを再起動しましたが、バグはまだ発生しています-他の手がかりはありますか？ ここで必死になって...

サーバーをチェックするための適切なsshセッションをすぐに実行できない場合は、powerlineをアンインストールする必要があります:(

これを修正するために、時計の代わりにストップウォッチを使用しました。 したがって、 /usr/share/powerline/config_files/themes/powerline.json 、これらの行を変更しました

"time": {
    "before": "◴ "
},

に

"time": {
    "before": "⏱ "
},

@binarykitchen構成は、電源がオンになっているマシンから取得されます。 シンボルの表示はクライアントで行われます。 現在提案されている修正は、構成の変更です。

テーマを構成しなかった場合は、バージョンを開発するためにすべての電力線を更新するだけで、デフォルトで問題のあるシンボルのないテーマを使用するようになりました。

ストップウォッチの修正を試しましたが、いや、それは役に立ちませんでした

電力線をアンインストールするだけだと思います-ごめんなさい

@binarykitchenたぶん、時計アイコンの代わりにスペースを使用するだけです。

@binarykitchenファイルを変更するだけでは不十分です。 また、電力線に新しい構成を使用させる必要があります（おそらく再起動が最も簡単です）。 たぶんそれは古い設定を使用している電力線デーモンなので、それを殺すこともうまくいくかもしれませんが、私にはわかりません。

@ liuhuiping2013上記のコメントも読みましたか？