Powerline: Gnome 3.22支持

电力线确定要显示的内容，并将其正确写入终端是tmux的责任。 您的屏幕截图看起来像是

1. tmux错误地认为终端比实际宽一个单元。
2. 对于一个字符，tmux认为它是一个单元格宽，而终端仿真器则认为它是两个单元格宽。

电力线对此无能为力。 您可以通过选择另一组字符来解决该问题（例如，将top_level主题设置为ascii或找出并覆盖一个有问题的字符），但这是一个tmux错误。

看起来@frol也在Gnome上。 我对tmux 2.3.1没任何问题，根据Arch软件包管理者的说法，它在9月30日进行了更新。看起来更像是Gnome终端的问题，或者由于一些神秘的错误而导致的电力线问题。 不带电源线的tmux在Gnome 3.22中可以正常工作。

与urxvt配合正常！

在powerline.json中更改：

至

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

@mrmodolo是的，这有帮助！

@burningTyger我正在使用testing回购，因此我在同一天获得了Tmux 2.3.1和Gnome 3.22，只是认为这是Tmux不兼容，但似乎我错了。

@mrmodolo ，手表符号是罪魁祸首，但是其他符号在我的电力线字体中不可用，因此我只将before字符串留空，这也解决了它。 谢谢。

在我的配置中，“”是UTF8 char f017 。
您可以在VIM中打印符号：
更改为插入模式；
CTRL + v，然后键入uf017

引起问题的手表符号是哪个Unicode字符（在上一则评论的黄色背景屏幕截图中）？

（注：U + F017在私人使用面积，我的系统上它同样出现在波浪号（〜）符号，但也许这是一个显示为您的系统上？如果是的话是什么做的手表@ mrmodolo实际上建议更改？

$ printf“％d \ n” \'
8986
$ echo“ obase = 16; 8986” | 公元前
231A

在VIM中：
CTRL + v，然后键入uf231A

现在我有了这个！

我正在使用Arch，但是Ubuntu默认在电力线中使用uses！

所以...我是否正确：

• 如果使用U + 231A，它将无法正常工作，
• 用U + F017而不是在同一位置正确工作？

（或者是相反的方式？对不起，我很迷茫。）

就我而言，在相同位置的U + F017可以正常工作！
我的配置文件是：

“时间”： {
“ before”：“”
}，

首先，我阅读gnome-terminal bugreport，这是一个bash / zsh电力线提示，但行为不当。 看这里的截屏，我觉得它是电力线tmux状态栏。

有人可以指出我要使tmux配置为电力线时应该遵循的最快最短的文档（这样我才能重现此错误）吗？ 我从未使用过电力线，而且我对tmux也不甚熟悉，而Google让路太多了。 我很乐意调试此问题，但是我没有时间熟悉电力线生态系统。 提前致谢！

我正在使用拱门...
yaourt -S python-电力线

在.tmux.conf中...
运行shell“ powerline-daemon -q”
源代码“ /usr/lib/python3.5/site-packages/powerline/bindings/tmux/powerline.conf”

如果tmux认为问题是U + 231A更宽，则GNOME终端认为是问题，那么该问题应该完全可以重现，而无需电力线：只需使一些status-选项包含此符号即可（注意：我不确定是否以及tmux使用哪种渲染优化，因此status-right应该包含一些内容）。

感谢您的信息！

我在使用手动编译的tmux-2.3和gnome-terminal / vte git的Ubuntu Yakkety（gtk + gnome 3.20 / glib 2.50.0 [属于gnome 3.22] / glibc 2.24）上。 我无法重现此错误（既不能使用电力线，也不能使用简单的状态权限）。

如果tmux认为U + 231A更宽，则GNOME终端会认为

这不能解释当前的问题。 然后，tmux会少打印一个字符（因为它认为一个字符较宽），因此不会填满整个宽度。 我认为是相反的：tmux认为它是常规字符，而gnome-terminal则认为它是两倍宽度。 因此它溢出。

如https://bugzilla.gnome.org/show_bug.cgi?id=762052#c30所述，gnome-terminal（vte）使用g_unichar_iswide（）而不是wcwidth（）（xterm和tmux也可能使用） 。

您可以尝试以下方法：

echo $'\u231A' | wc -L

这将打印glibc的wcwidth（），我假设输出为1。

echo ABCDE; echo a$'\u231A'cde

大写字母和小写字母是否正确对齐？ 我猜想在xterm中它们会这样做，而在gnome-terminal中它们不会（手表占用2个单元）。

您能否分享您的glib和glibc版本？ 我的疯狂猜测是，您有glib 2.50.1，其更改日志中显示“将Unicode支持更新为Unicode 9.0.0”，也许Unicode 9.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

手表和沙漏的代码点（可能还有更多）被Unicode 9.0.0扩展了。

如果gnome-terminal与glib 2.50.1或更高版本一起运行，则gnome-terminal使用新的宽度，而xterm和tmux依赖于最新版本（2.24）仍使用旧宽度的glibc。

我在这里找不到链接的gnome-terminal bugreport，因此在这里供您参考：
https://bugzilla.gnome.org/show_bug.cgi?id=772812
https://bugzilla.gnome.org/show_bug.cgi?id=772890

大写字母和小写字母是否正确对齐？ 我猜想在xterm中它们会这样做，而在gnome-terminal中它们不会（手表占用2个单元）。

我使用此符号还有另一个可能的故障：konsole和tmux都认为它是一个单元格宽，但是没有（不能？）告诉字体渲染库将其缩放到该显示单元中（实际字形取自另一种字体，因为总站没有此字形），导致类似

。 但这并不会导致这里的人遇到问题，但这会使您的测试产生不正确的结果。

konsole是我所知道的唯一仿真器，它可以做到不与单元格对齐的疯狂行为。

在所有其他仿真器中，监视符号可能会溢出到c的单元格中，但字母将彼此正下方：Cc，Dd，Ee或（如我期望的那样在gnome-terminal中使用glib-2.50 .1）Dc和Ed将对齐。

我在Arch x86 + tmux上有同样的问题。 但是，编辑出主题/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 ，但是在此示例中输出是相同的。 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 :

谢谢，我修好了。

像魅力一样工作。
仅供参考： U + 23F2后面有两个空格，看起来像旧的一样（除了没有破损）。 仅使用计时器时钟而不是手表。

其他可能但未经测试的字符是：
U + 23F0 （闹钟）
U + 1F570 （壁炉钟）
U + 1F570至U + 1F567 （除钟面）

感谢您的解决！

由于这仍然存在问题，如果您的配置文件设置为使用Unicode版本9字符宽度，则新版本iTerm2上的OS X / macOS用户可能会遇到此问题-此处的解决方法是仅取消选中“首选项”->“配置文件”下的复选框->文本-> Unicode。

在Ubuntu 16.10上突然出现此问题-上周没有发生。 奇怪的。 可能在apt-get更新或pip升级期间发生了某些变化，不记得了。

那么正式的解决方法是什么？

@binarykitchen昨天也一样！

找到了解决方案

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

然后编辑〜/ .config / powerline / themes / powerline.json并找到一个显示以下内容的块：

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

我将“之前”的值替换为“◴”

@CVirus谢谢，但就我而言，已经有了watch char。

但是我的.config文件夹中没有json文件...这可能是原因吗？

在此线程顶部的一些注释表示要删除或替换watch char。 困惑。

@binarykitchen用我粘贴的时钟或其他任何字符替换您的时钟

@CVirus会这样做-澄清一下，替换字符后我是否必须重新启动某些程序？ 我的机器，zsh会话？

需要明确的是，它仅在与我的远程服务器进行tmux会话期间发生。 而且我只是在客户端（而不是服务器端）更正json。

让我知道 ...

@binarykitchen您需要重新启动电力线驻留的任何进程。这很可能意味着电力线守护程序，而不是shell或tmux。 尽管zsh在这里很特殊：如果您安装了zpython，那么电力线将存在于Shell进程中。 除非您自己安装了zpython，否则这种情况不太可能发生。

@ZyX-谢谢-不知道我是否已安装zpython和btw，我已经通过apt-get（不是pip）安装了电力线。

并重新回答我的最后一个问题：“它仅在与远程服务器的tmux会话期间发生”-我如何找出电源线问题是在客户端还是在服务器端？

@binarykitchen无论应用程序使用电力线是什么，它都会在运行侧使用电力线。

@ ZyX-I“无论使用电源线的应用程序是什么，它都会在运行的一侧使用电源线。”

->我的问题是，当我通过tmux运行ssh会话时，我开始认为这是服务器端电力线安装的问题。 但是我对电力线的了解更多，我想这是客户端的问题。 这真的很抽象...

重新启动了我的机器，但该错误仍然发生-还有其他线索吗？ 在这里变得绝望...

如果我很快无法通过适当的ssh会话来检查服务器，则必须卸载电力线:(

我只是用秒表而不是时钟来解决这个问题。 所以在/usr/share/powerline/config_files/themes/powerline.json ，我更改了这些行

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

至

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

@binarykitchen配置是从机器电源线上打开的。 显示符号发生在客户端上。 当前建议的修复方法是更改​​配置。

如果您未配置主题，则只需更新所有电力线以开发版本，则默认情况下它将使用没有问题符号的主题。

尝试了秒表修复程序，但是，那没有帮助

认为我会卸载电力线-抱歉

@binarykitchen也许只使用空格而不是任何时钟图标。

@binarykitchen仅更改文件是不够的。 您还必须使电力线使用新配置（也许重新启动是最简单的）。 也许它是使用旧设置的电力线守护程序，所以杀死它也可能起作用，但是我不确定。

@ liuhuiping2013您甚至没有阅读以上评论？