Hi Eli,
> So we will some day have one such terminal emulator. That's good, but
> a text-mode application that needs to support bidi cannot rely on its
> users all having access to that single terminal.
No. A text-mode application that needs to support BiDi must do the
BiDi itself and pass visual order to the emulator, and beforehand
switch the emulator to explicit mode so that you don't end up with
"double BiDi". Once you emit visual order, there's no need for any
BiDi control characters.
For this behavior, the only feature you need from a terminal emulator
is to have a mode where it doesn't shuffle the characters. Currently
every emulator I'm aware of has such a mode, although in some of them
you have to tweak the settings to get to this mode (in my firm opinion
it's an unacceptable user experience), while in emulators according to
my specification there'll be an escape sequence for text-mode apps to
automatically switch to this mode.
What BiDi control characters (LRE, LRI, FSI etc.) in implicit mode
will give you – if supported – is that you'll be able to execute "cat
file", and it'll be displayed correctly, even taking FSI and friends
as present in the file into account. Of course this will only work in
terminal emulators that support this.
> This is indeed a significant issue, because it means applications
> cannot force the terminal use a certain non-default base paragraph
> direction.
They can, since there's a dedicated escape sequence (SCP) for setting
the base paragraph.
That being said, not being able to remember FSI at the beginning of a
string is indeed a significant issue, we agree on this. We just need
to figure out how to alter the emulation behavior to remember them,
which I find the next big step to address in the specification.
cheers,
egmont
Received on Fri Feb 01 2019 - 06:54:55 CST
This archive was generated by hypermail 2.2.0 : Fri Feb 01 2019 - 06:54:55 CST