Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Make wcwidth configurable #4816
This adds the cmake option
Both default to enabling our fallback, but can be set to use the system's wcwidth again.
On my system, this would fix #4306.
Ideally, this would default to using the system wcwidth instead - as noted in #4571, it doesn't really matter whether we get the width "right". What matters is that we get the same width that the terminal gets, and that's much more likely with a shared implementation. I have gotten vte, urxvt, st and xterm to disagree with my right-prompt, which causes an interesting stair-case effect that makes fish nigh-unusable.
As previously noted, I suck at build systems, so someone checking this would be much appreciated.
The cmake and configure options name are unclear; I used the wrong one at first. I suggest using:
It works as expected when I use
Note that I have no problem building master fish with cmake.
Makes sense, yes.
I don't think this branch should change anything about that. Did you build with cmake previously?
Well, I guess compiling with autotools then with cmake doesn’t work very well, because it works with a clean clone. Well, I guess because when I build fish with cmake, master or your branch, it’s so broken I can’t test emojis: when I launch
Maybe worth another issue though.
I was wondering if we shouldn’t make the workaround opt-in: I think it makes more sense that the default is using the system
Mine, for instance. Archlinux with glibc 2.26. If I use either
with my right-prompt, I'll get a nice little staircase-effect like this:
(That's after I've typed one "e" in each of the terminals - though note that in this case the suggestion is also triggering it)
One of the offenders is \U26A1 ("HIGH VOLTAGE SIGN").
But the point is, and I've brought this up before, that even if we squash that one, others may pop up.
And, as I've said in #4571 (where the terminal rendered a zero-width-space with a width that was not zero), sometimes it's better for us to be wrong in the same way as the terminal.
And while it's certainly not perfect to rely on the system wcwidth (they frequently have bugs), it's the best chance we have to get the same value as the terminal. And if the terminal uses its own implementation, there's nothing we can do that won't break fish for all other terminals.
So I've come to believe that we really should use the system wcwidth. This PR is a compromise so that people on old systems or weird terminals that we can't test before the next release can still use fish.
Long term, I'd love it if we switched the default to system wcwidth and let people on RHEL 6 and the like build it with the internal one (because of stuff like ssh - where you have a terminal on a new system, with a new wcwidth, but a shell on an old one). But there's no real harm in being a little conservative.