3 ms·

It's tempting, and thank you for the PR, but, do we then have to push a new Mosh release every time there's a Unicode update? And the users have to get this rel

It's tempting, and thank you for the PR, but, do we then have to push a new Mosh release every time there's a Unicode update? And the users have to get this release installed on both the server and their client? It seems... like it fixes part of the problem, sure, by us taking on more of the load and locking us into an annual release cadence. I think if we give up on libc, my "perfect" solution would probably be something like: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width (probably we can do this in some smart way) (b) client somehow communicates this info to the server at runtime, over the protocol. But that's a lot of protocol work and kind of annoying. The good-enough solution might be: (a) user runs a script that prints every single Unicode character in their local terminal and learns its width, or perhaps user just runs your script on the Unicode tables (+ user-supplied info about how their terminal handles ambiguous-width East Asian characters) (b) user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir. I think the current maintainership has their own idea of what they want to do that's not quite this either.

faho 5y ago
>thank you for the PR Just to be clear: It's not my PR. The person who made that must've just seen widecharwidth and thought it was a potential solution. >do we then have to push a new Mosh release every time there's a Unicode update? In theory, yes. In practice the new codepoints take long enough to be available anywhere and there are few enough of them that being a bit out of date isn't a problem. (case in point widecharwidth is still on Unicode 12 apparently - I should update that) >user runs a script that prints every single Unicode character in their local terminal and learns its width And they would have to re-run that regularly, whenever the terminal updates or they switch. >user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir. And they would have to do all that setup. That's a lot of annoyance to put on your users when you can solve 99% of the problem by just incorporating a semi-up-to-date width table yourself. The perfect is very much the enemy of the good here.

faho 5y ago

>thank you for the PR Just to be clear: It's not my PR. The person who made that must've just seen widecharwidth and thought it was a potential solution. >do we then have to push a new Mosh release every time there's a Unicode update? In theory, yes. In practice the new codepoints take long enough to be available anywhere and there are few enough of them that being a bit out of date isn't a problem. (case in point widecharwidth is still on Unicode 12 apparently - I should update that) >user runs a script that prints every single Unicode character in their local terminal and learns its width And they would have to re-run that regularly, whenever the terminal updates or they switch. >user is responsible for distributing this data file to every server they feel like connecting to and putting it in some well-known location in their homedir. And they would have to do all that setup. That's a lot of annoyance to put on your users when you can solve 99% of the problem by just incorporating a semi-up-to-date width table yourself. The perfect is very much the enemy of the good here.