Bidi paragraph direction in terminal emulators

[Egmont Koblinger via Unicode]

On Sat, Feb 9, 2019 at 8:13 PM Eli Zaretskii <eliz at gnu.org> wrote:

> That's the application's problem, not the terminal's.  An application
> that wants its column to line up _and_ wants to support complex text
> scripts will need to move cursor to certain coordinates, not to assume
> that 7 codepoints always take 7 columns on display.

In order to do that, an application needs to know how wide a text will
appear, which depends on the font. How will it know it?

Will it by some means know the font and the rendering engine the
terminal uses (even across ssh) and will it have to measure it itself?

Or will it be able to ask the terminal? If so, how? Maybe a new
extension, an asynchronous escape sequence that responds back with the
measured width? What about the latency caused by the bunch of
asyncronous roundtrips, especially over ssh? What about the utter pain
and intrinsic unreliability of handling asynchronous responses, as
I've outlined in a section of
https://gitlab.freedesktop.org/terminal-wg/specifications/issues/8 ?

What if there's no font? What if there are multiple fonts at the same
time? What if the font is changed later on, is it okay then for the
display of existing stuff to fall apart and only newly printed stuff
to appear correctly?

How do you define the "width of the terminal in characters", get/set
by ioctl(..., TIOC[GS]WINSZ, ...) that many apps rely on?

If you define it by any means, what if by placing the maximum numbers
of "i"s in a row doesn't fill up the entire width? Will that area be
unaccessible, then? Or despite having a definition of terminal width,
will there be new cells beyond this width to write to?

What if filling a row with all "w"s overflows? I take it that an app
shouldn't print there, but what if it still does, will that piece of
text just not be shown?

How much more complicated would you think implementing something like
"zip -h" become?

> How is this different from using variable-pitch fonts?

Do you mean variable-pitch font where the terminal still places each
glyph in its designated area? The font is the private business of the
terminal emulator, then, it'll just appear ugly as a screenshot I've
already linked, but the emulation behavior wouldn't care.

Or do you mean variable-pitch font where each letter is placed after
each other, as you'd expect in document editors? That is, way more
"i"s that "w"s fitting in a line? It's not different, it's practically
the same. And this is something that none of the terminal emulators
I'm aware of does; and having some clue about terminal emuators, I
can't imagine how one could do (see all the questions above for a
start).

This is why I'm saying: Sure you can take this path, but then we're
talking about something new, not terminal emulators as we currently
know them. You can take this path, but then you'll have to rebuild
many of the already existing apps, and beware, they'll get way more
complex.


e.