Bidi paragraph direction in terminal emulators BiDi in terminal emulators
Egmont Koblinger via Unicode
unicode at unicode.org
Wed Feb 6 17:45:55 CST 2019
> Not necessarily. One could allow the first strong character in the
> prompt to determine the paragraph directions
How does Emacs know what's a prompt? How can it tell it from the
previous and next command's output?
Whatever it does to know where the prompt is, can it be made into a
standard, cross-terminal feature?
> That's what the Emacs
> terminal (invoked by M-x term; top level definition in term.el) does.
I tried it. Executed my default shell, and inside that, a "cat
TUTORIAL.he". All the paragraphs are rendered as LTR ones,
left-aligned. Not the way the file is opened in Emacs.
If you claim Emacs's built-in terminal emulator supports BiDi, I'm
kindly asking you to present a documentation of its behavior, in
similar spirit to my BiDi proposal.
> Not necessarily. One might use cat to glue together files that had
> split into 1400k chunks, in which case it is not even reasonable to
> expect the end of file to be at a character boundary. (Yes, floppy
> disks still have their uses.)
I did not say anything about changing cat's behavior. I recommended to
change the convention for such paragraph-oriented text files to end
with two newlines.
> But the white space between paragraphs is a separator, not a
> terminator. One doesn't require it at the end when formatting
> paragraphs within the cell of a table.
Does this logic also apply to single newline characters? If not, why
not, what's the conceptual difference? If it does, why do text files
end in a newline?
More information about the Unicode