Re: bug#16961: left-char moves to beginning of line; visual-order-cursor-movement

[Eli Zaretskii]

> From: David Reitter <address@hidden>
> Date: Fri, 7 Mar 2014 21:38:38 -0600
> Cc: M A <address@hidden>,
>  "address@hidden developers" <address@hidden>
> 
> On Mar 7, 2014, at 2:03 PM, Eli Zaretskii <address@hidden> wrote:
> 
> > HL Line Mode, the Mother Of All Evil…
> 
> Couldn’t the core of this be implemented in redisplay instead of in Lisp?

Indeed, I think it could be, similarly to the current implementation
of the region highlight.  Volunteers are welcome.

> (I’m assuming it places overlays in the buffer.)

It moves an overlay in a post-command-hook, which makes the window
display "non-current", and disables a lot of redisplay optimizations
as result.  The default mode of operation of visual-order
cursor-movement is to traverse the glyph matrices that describe what's
on the glass, but it can only do that if the display is marked
"current".  Otherwise, it falls back to Plan B, which is much trickier
(it needs to simulate the display without actually performing it), and
where the use of word-wrap caused this bug.

> > Does this mean "Aquamacs without customizations" has
> > visual-order-cursor-movement set to t?  If so, I think it's not a good
> > idea at all: that variable is user-level customization, it shouldn't
> > be forced on the users.
> 
> Users can change it the way the want it.

Users can change the default no matter what its value.  The question
for defaults is what would most of the users want.

> Aquamacs just sets a different default, as it does with a lot of settings.

I'm talking specifically about this one.  You will notice that I
didn't say anything about turning on visual-line-mode by default.

> The reason why I’m doing this is that otherwise, left/right keys do not move 
> left/right movement of the cursor (in RTL or mixed text), and that would be 
> incoherent with other situations in the system where users edit RTL text.

What other situations with bidirectional text trigger different
behavior?  And what do you mean by "the system" here?

Anyway, AFAIK most, if not all, of the apps that support bidirectional
text default to logical-order cursor movement.  Some don't even
support visual-order movement as an option.  Visual-order movement
might look nice to someone who doesn't speak languages which use
bidirectional scripts, but it is seldom needed by those who do speak
them, because in some contexts it moves the cursor into a place that
is significantly different from where it should be according to the
reading order.  Their other effects are also weird, e.g. try moving
the cursor with the Shift key pressed, and watch the region highlight.

So I expect your default to be a significant surprise for users of
bidirectional scripts.  OTOH, users of unidirectional scripts will
never notice it (apart of bugs such as this one), because the effect
is indistinguishable from logical-order movement.  The only effect on
users of unidirectional scripts is that cursor motion is more
expensive in CPU usage than the logical-order movement, which is
hardly a good trade-off.

> Do you have a better suggestion?

Yes: keep the upstream default for this one.  Its value is not an
accident, but rather well thought-of.