-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Take (xft) font(s) into consideration? #1
Comments
I've created hack for rxvt-unicode to inject a |
Here is some discussion / ideas to make shells (Zsh in this case) behave better: http://www.zsh.org/mla/workers/2016/msg02326.html. |
Sorry for the late reply! There are a lot of implementations of wcwidth(): this one, wcwidth in python, gnulib, glibc, wcwidth in nodejs, wcwidth in ruby, wcwidth in lua. utf8proc is getting more popular where people are using Using something along your proposal wouldn't work with these freestanding implementations and is fragile and hard to work across e.g. ssh sessions across systems. I think we need to standardise the width of code points (including private plane ones when necessary) in fonts intended to be used in terminals as well as possible, and then push out that to various wcwidth implementations. |
I am looking into rxvt-unicode's handling of wide characters once again, and
found the following:
The NerdFileTypes font for example seems to use private use codepoints:
E.g. 0xe612 () is defined as:
Source: https://github.com/ryanoasis/nerd-fonts/blob/72ca7b7c1f9e8e3c5e319e0703fd95fc827bf3b9/glyph-source-fonts/original-source.otf.
According to https://codepoints.net/U+e612 this is "U+E612 PRIVATE USE CODEPOINT", with Ambiguous East Asian Width, where http://unicode.org/reports/tr11/#Ambiguous says
This could be interpreted as "let the font decide", and therefore I've looked
into using the following method in rxvt-unicode to ask the font for the actual
width:
Using this in rxvt_term::scr_add_lines then:
While this method works well for rxvt-unicode (but is slow, of course), it does not play well with the shell/programs being used therein (just like some custom wcwidth implementation).
Therefore this would need to be provided through
wcwidth
itself.Do you think it would be feasible to add support for something like this to this library/project?
I could imagine this being opt-in, e.g. through defining some environment variable (containing a list of fonts, since for rxvt-unicode only a defined list would be used).
Also this would need to have some caching in place then probably.
The obvious workaround is to patch (this)
wcwidth
to just return what you expect, which works well already.The text was updated successfully, but these errors were encountered: