Use of U+2630

[laburnumT]

trafficstars

In commit 4298c5f472a05486d6e26988cf10f4d04c80afd2 vim added the code range 2630-2637 to the double width characters messing up the ☰ used in section Z from the README.

Maybe using code point U+2261 would be a better fix? It is listed as ambiguous as related to its east Asian width, but is interpreted as a half width character for now.

Making this change resolves the issue for me.

A potential pull request: https://github.com/vim-airline/vim-airline/pull/2690

[chrisbra]

I am not convinced. Experience shows, that changing those characters, it breaks for some people, because there are display issues on some terminals. Best to leave the current default and adjust to you liking using the existing configuration settings.

[laburnumT]

I could definitely be misunderstanding what is going on. As I have never looked at full or half width chars before. But either removing 2630 from the list in vim, or changing 2630 to 2261 in airline fix the issue in both the gnome and xfce terminals.

Though I can also overwrite this locally if this problem seemingly does not show up for others.

[shadowwa]

I also have this problem in Konsole and kitty terminals. In my case, replacing maxlinenr symbol was not enough, I also have to replace the whitespace symbol ("\u2632") otherwise the statusline was messed up when buffer contains trailing spaces I've ended adding in my .vimrc:

let g:airline_symbols.maxlinenr = '≡'
let g:airline_symbols.whitespace = 'Ξ'

[PatTheMav]

I've noticed the same issue in Terminal.app. Just so I understand the issue right: The reason why I (and others) get a new "gap" in the airline is because the code treats U+2630 as an asian double-width character, but some terminals (like Terminal.app) do treat it as single-width and thus don't "fill" the space?

EDIT: Interestingly, Terminal.app has a setting to treat "East Asian Ambiguous" characters as wide characters, but that only seems to affect Powerline symbols. U+2630 is also rendered wide in Textedit, but seems to be shrunk into a monospaced width in the Terminal, which looks like a specific rendering choice of the Terminal to me.

Could be a chicken and egg issue - it probably was beneficial for Terminal emulators in the past to just scale wider characters down to single width to ensure visual compatibility, which will now break with code that internally assumes "correct" widths.

[chrisbra]

Hm, actually I noticed the same issue with putty. But haven't had time to track this down. Should probably re-consider #2690