> From: Egmont Koblinger <egm...@gmail.com> > Date: Tue, 5 Feb 2019 01:32:34 +0100 > Cc: unicode@unicode.org > > On the other hand, it's not unreasonable for higher level stuff (e.g. > shell scripts, or tools like "zip") to use such control characters.
Yes, but most of them won't ever do that. > > No, this simple case must work reasonably well with the application > > _completely_ oblivious to the bidi aspects. If this can't work > > reasonably well, I submit that the entire concept of having a > > bidi-aware terminal emulator doesn't "hold water". > > There isn't a magic wand. I can't magically fix every BiDi stuff by > changing the terminal emulator's source code. I didn't say "magically fix", I said "work reasonably well". I think it would be a mistake to demand that any alternative to the default each-line-is-a-new-paragraph method must be perfect. It should be enough if an alternative is better. > What my specification essentially modifies is that with this > specification, you at least will have a chance to get the mode right. My experience is that this is an important feature to have, but it will (maybe even should) be used rather rarely. In most cases you will just have plain text. Moreover, emitting the control sequences that set the mode is in itself a complication, because if the terminal doesn't support them, the result could be corrupted display. You will need methods of detecting the support, and those detection methods usually involve sending another control sequence to the terminal and waiting for response, something that complicates applications and causes delays in displaying output. > In case of "zip", the creators of that software know exactly how the > output should look like Not necessarily true. The translations are normally prepared by people who are experts only in translating messages, they don't necessarily consider layout issues, because for that you'd need to look at the code or even run the program, something translators are unlikely to do. > If you're about to internationalize your software, this layout is a > pretty bad choice. Tell me about that! But the reality is that this is what you get, and IMO the solution for displaying this on a terminal should work reasonably well with that. > This kind of formatting also ignores that English is a pretty dense > language, in other languages the strings tend to become longer. Actually, some/many RTL scripts tend to produce shorter text, because vowels are not written, and because many words have very short roots. But this is a tangent.