Bidi paragraph direction in terminal emulators

[Egmont Koblinger via Unicode]

Hi Philippe,

> The monospace restriction is a strong limitator: but then I don't see why a "terminal" could not handle fonts with variable metrics, and why it must be modeled only as a regular grid of rectangular cells (all of equal size) containing only one "character" (or cluster?).

Because this is what a "terminal" currently is, this is one of the
basic assumptions around which gazilliions of libraries and
application were built up.

Just one example: A utility might query the width, let's say it's 80
columns. Then it can print either 81 "i"s, or 81 "w"s, and in both
cases it can be sure that the last one will be aligned exactly below
the first one.

You can sure change this. But then you'll have to heavily adjust the
behavior of all the screen drawing libraries and all the applications
that use these libraries or do their own screen handling. It's out of
the scope of my work to do anything like this. If you feel like, I
encourage you to go ahead, put your work in it, and present a proof of
concept.

> So using controls, you would try to mimic again what HTML already provides you for free (and without complex specifications and redevelopment).

Show me that "without complex specifications and redevelopment"
because all I see is the need to heavily rewrite plenty of libs and
tools that were created and continuously developed during the last few
decades. I don't really see this approach feasible. Feel free to prove
me wrong by presenting software that works on top of the redefined
terminal emulator concept, at least on a proof on concept level. For
starter, I'd love to see a shell with interactive line editing (like
bash, zsh), and one application that uses vertical alignment heavily,
let's say "top" or anything similar, using proportional font in your
newly created world.


cheers,
egmont