Re: `C-b' is backward-char, `left' is left-char - why?

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Date: Tue, 07 Jun 2011 10:51:13 +0200
> 
> I have thought about it, and I guess the key point is ambiguity of
> cursor display.  The cursor is usually displayed just after the last
> inserted character.  Which means to the left in R2L contexts, and to the
> right in L2R contexts.  For a vertical cursor between characters, this
> means that
> 
> LLLL^RRRR
> 
> is ambiguous: we are either at the end of the LLLL passage, or at the
> end of the RRRR passage.

Right.  As I wrote, there are two places on the screen where we could
display the cursor in these cases, and TRT would be to display
something in each one of them.  It would also make sense to make the
whole range of characters between these two spots stand out in color
or something.

There's some discussion of these issues here:

  http://www-01.ibm.com/software/globalization/topics/bidiui/index.jsp

> I think what is needed in this particular case is a virtual fill
> character (perhaps the direction switch glyph, but displayed with a
> different face?) at the insertion point when we are inserting in reverse
> paragraph direction and the cursor would be displayed on a forward
> paragraph character (including newline), not logically adjacent to the
> insertion point.  Either that, or generally switch cursor type for
> reverse direction insertion, so that one knows whether one has an L2R or
> R2L facing cursor.

Sorry, I don't understand the details of your proposals.  It would
help if you show some pictures.  (What are "direction switch glyph"
and "forward paragraph character"? what "cursor type" do you want to
switch to? etc.)

> > Actually, TRT would be to split the cursor in two, because it plays
> > two different roles whose correct positions in this case do not
> > coincide.
> 
> They diverge only on borders between L2R and R2L, and a virtual padding
> like described above gives the cursor a buffer that allows it to never
> split.

IIUC, your "virtual padding" is just one possible implementation of a
split cursor.  But what does "gives the cursor a buffer" mean?

> > That would need an even deeper surgery, including in terminal-specific
> > parts -- xterm.c, w32term.c, etc.  And what to do on a TTY with its
> > hardware cursor?
> 
> The virtual padding approach should work on a tty since it requires only
> one cursor to display.

Maybe I'll agree once I understand what you propose.  Right now, I
cannot judge if everything you propose can work on a TTY.  In any
case, the redisplay interface for displaying the cursor would need to
change, because we will now compute 2 locations, not 1.