Proposal for BiDi in terminal emulators

[Egmont Koblinger via Unicode]

Hi,

> Arabic terminals and terminal emulators existed at the time of Unicode 1.0.

I haven't found any mention of them, let alone any documentation about them.

> If you are trying to emulate those services, for example so that older software can run, you would need to look at how these programs expected to be fed their data.

My goal is not to have those ancient software run. My goal is to look
into the future. Address the requests often seen in current terminal
emulator's bugtrackers. Stop the utterly unacceptable user experience
of current self-proclaimed BiDi-aware terminals where in order to run
Emacs you need to fiddle with the terminal's settings. Show that BiDi
in terminals is a much more complex story than just shuffling around
the characters, thus stopping new emulators from taking this broken
route which causes about as much damage as good. Create a platform on
top of which modern BiDi-aware experience can be created, to make both
"cat" and "emacs" work properly out of the box for BiDi users.

> I see little reason to reinvent things here, because we are talking about emulating legacy hardware. Or are we not?

As per the above, no, not really. I'm not aware of any hardware that
supported BiDi, was there any? I look at terminal emulators as
extremely powerful tools for getting all kinds of work done. They are
continuously being improved, nowadays many terminal emulators contain
plenty of features that weren't there in any hardware one. I'm looking
for smoothlessly extending the terminal emulator experience to the RTL
/ BiDi world.

> It's conceivable, that with modern fonts, one can show some characters that could not be supported on the actual legacy hardware, because that was limited by available character memory and available pre-Unicode character sets. As long as the new characters otherwise fit the paradigm (character per cell) they can be supported without other changes in the protocol beyond change in character set.

Which protocol, the protocol of non-BiDi-aware terminals that lays out
everything from left to right, so the output of "echo", "cat" etc. are
reversed; or the protocol of self-proclaimed BiDi-aware terminals
where it's literally impossible to create a proper BiDi-aware text
editor?

My work focuses on proving that both of these modes are needed, and
how the necessary mode switches could happen automatically behind the
scenes.

> However, I would not expect an emulator to accept data in NFD for example.

Many emulators do.


cheers,
egmont