4 ms·
I like that the test started with Unicode support, but there is a lot more that could be tested. See http://www.madore.org/~david/misc/unitest/ http://www.mador
by unhammer 9y ago
I like that the test started with Unicode support, but there is a lot more that could be tested. See http://www.madore.org/~david/misc/unitest/ http://www.madore.org/~david/misc/unitest/ for some more challenges, in particular http://www.madore.org/~david/misc/unitest/#combining http://www.madore.org/~david/misc/unitest/#combining
Last time I compared terminals re:Unicode, I settled on sakura (over xterm, urxvt, st, xfce4-terminal at least). I should probably try mlterm too, but since I don't understand any RTL languages myself, I actually find it less confusing if they are "backwards", especially when they occur in the middle of non-RTL strings. https://opensource.com/life/16/3/twisted-road-right-left-language-support https://opensource.com/life/16/3/twisted-road-right-left-lan... is a scary look at the possibilities for misinterpretation – keeping everything in byte order at least makes it predictable and unambiguous, though "wrong".
-----
By the way, `set enable-bracketed-paste on` really should be default, that's an instant productivity enhancer! I used to think it was impossible to paste tabs into the terminal …
- tssva 9y agoA lot of these RTL issues seem to properly belong to the application generating the output and not the terminal. A terminal displays what an application tells it to. It should be up to the application to properly tell the terminal to display the text RTL and left or right aligned and not up to the terminal to try to decipher what the application wants. The article itself has an example of this. It contains RTL language which should not be right aligned because it properly belongs in line with the rest of the text. How is a terminal suppose to know this without the application telling it. The application is the one with knowledge of the context.