On Wed, Jan 30, 2019 at 3:32 PM Adam Borowski <kilob...@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