Bidi paragraph direction in terminal emulators BiDi in terminal emulators

[Egmont Koblinger via Unicode]

Hi Richard,

> 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?


e.