Comment 49 for bug 263822

Re Diego:

You are basically right. I'd like to add a couple of points.

As for complex apps such as mc, your approach (2) cannot work. This is because the BiDi algorithm would not just need to shuffle around characters that are visible in the terminal; it might need to pull offscreen chars onscreen and vice versa. E.g. think of mcview's unwrapped display mode, and long lines so that you need to scroll horizontally to read the file. In order to properly display the BiDi text, the terminal would need to be aware of the entire logical line of the file, however, the application (e.g. mcview) simply doesn't give this data to the terminal. So, for complex apps it's solely your approach (1), that is, BiDi done in the applications that can work.

On the other hand, it's a reasonable expectation that a simple "cat" produces readable text. Hence a terminal emulator should, by default, probably perform a BiDi for each logical line (that is, between explicit newlines). Which brings in a further question about how further cursor positioning or character overriding should work in this case. I've discussed it in https://bugzilla.gnome.org/show_bug.cgi?id=321490#c29, I believe #2 there would be the right thing to do (and the one that does not terribly break the look of ncurses apps).

So, we would already need two terminal modes, probably controllable via an escape sequence. Implicit BiDi (the default) is when VTE applies the BiDi algorithm (this is I guess what konsole does), which fixes simple utilities, whereas probably breaks complex apps big time. And an explicit BiDi where VTE reverts to its current behavior, that is, does not do any BiDi, to be used by apps that perform the BiDi algorithm themselves.

I _guess_ this is what ECMA TR53 (also discussed in the aforementioned link) might be about, although I haven't had the chance to study it.