Re: Column numbering in bidirectional display

[David Kastrup <dak@gnu.org>]

Eli Zaretskii <eliz@gnu.org> writes:

> This might surprise at first, and might even look terribly wrong, but
> it turns out that users expect that in bidirectional text.  At least
> MS Word behaves _exactly_ like this, AFAICS.
>
> Moreover, this makes a surprising number of basic Emacs features work
> correctly even though the underlying Lisp code is entirely oblivious
> to bidi reordering.  One example is Dired, when file names include R2L
> characters: I was pleasantly surprised to see that it puts the cursor
> on the correct place within the file name.  Another example is the
> various features that manipulate indentation.
>
> If we decide that columns should be numbered in their screen order,
> from left to right, then we will need:
>
>   . Rewrite primitives in indent.c to be bidi-aware, i.e. advance by
>     calling functions from bidi.c rather than just incrementing
>     character positions.  This would complicate the parts that move
>     backwards, because there's no code in bidi.c that can do that, and
>     it's not trivial to write such code.
>
>   . Fix all the Lisp code that uses these primitives to not assume
>     that column zero is necessarily the first character of the line
>     that follows a newline.

It is my opinion that bidi reordering should be kept strictly a display
feature.

The function move-to-column is sort of a hybrid ("The column of a
character is calculated by adding together the widths as displayed of
the previous characters in the line.")  It is obvious that the quoted
sentence from the description raises more questions than it answers:
what are "previous characters" in this context?  Does the "width as
displayed" count positively?

Should the relation
(eq (<= (progn (move-to-column x) (point)) (progn (move-to-column y)))
    (<= x y))
be preserved?  That would make table formatting complex.

A command like vertical-motion acts on a display text presentation
rather than a logical representation: it would heed bidi (where
applicable).

Programmatically, text manipulation should keep as far away from those
display-oriented functions as possible (except where indeed the display
representation should be manipulated).  And all basic text manipulation
should stay

-- 
David Kastrup