Re: Proposal for BiDi in terminal emulators

On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski <kilobyte_at_angband.pl> wrote:

> > > ╒═══════════╤══════╕
> > > │ filename1 │ 123 │
> > > │ FILENAME2 │ 17 │
> > > └───────────┴──────┘

> That's possible only if the program in question is running directly attached
> to the tty. That's not an option if the output is redirected. Frames in
> a plain text file are a perfectly rational, and pretty widespread, use --
> and your proposal will break them all. Be it "cat" to the screen, "less" or
> even "mutt" if the text was sent via a mail.

I'd argue that if you have such a data stored in a file, with logical
order used in Arabic or Hebrew text, combined with line drawing chars
as you showed, then your data is broken to begin with – broken in the
sense that it's suitable for automated processing (*), but not for
display. I can't think of any utility that would display it properly,
because that's not what the Unicode BiDi algorithm run over this data
produces.

(*) but then line drawing chars are not really a nice choice over CSV,
JSON, whatever.

The only possible choice is for some display engine to be aware that
line drawing characters are part of a "higher level protocol", and
BiDi should be applied only in the lower scope. I don't think the
terminal emulator is the right place to make such decisions – I don't
think any other generic tool (graphical word processor, browser etc.)
does make such a call either.

cheers,
egmont
Received on Wed Jan 30 2019 - 08:44:08 CST