Re: arrow keys vs. C-f/b/n/p

[Lennart Borgman]

On Sat, Jun 12, 2010 at 8:58 PM, Lennart Borgman
<address@hidden> wrote:
> On Sat, Jun 12, 2010 at 8:33 PM, Eli Zaretskii <address@hidden> wrote:
>>> From: Lennart Borgman <address@hidden>
>>> Date: Sat, 12 Jun 2010 18:18:18 +0200
>>> Cc: address@hidden, address@hidden, address@hidden, address@hidden
>>>
>>> I think the default should be that cursor keys (and keys like page
>>> up/down) should move visually.
>>
>> You are talking as a typical L2R user, as in that case visual and
>> logical order are identical.
>
>
> I do not think visual motion actually has anything to do with that.
>
>
>> For users of R2L scripts, what you suggest is a disaster.  If cursor
>> motion is visual by default, one cannot even mark text by holding
>> Shift and moving point with the arrow keys.
>
>
> I see no reason for this. The arrow keys will with visual motion move
> just as they do if all the text where just L2R. So the visual part
> will work as before (on the user side, implementation may have to
> change).
>
> Converting the visual region you visually see on the screen to a
> logical range is a bit difficult, but not impossible.
>
> The difficulty is of course to decide what the range on the screen
> will be if the end points of the visual region happen to disagree
> about the direction. (If there are more difficulties then I am unaware
> of them at the moment.)
>
> The answer to this is as far as I can see that the visual region in
> this case no longer internally corresponds to a single range, but to
> two noncontinuous ranges in the buffer. If I am correct on this, is
> not this then a difficulty that must be handled to finish the bidi
> support?

I just tested in etc/HELLO to see how you have handled this. You took
another route than I expected and I think it makes sense.

When selecting a region with the two end points in parts with
different directions you instead split the visual region on screen.
(If anyone wonders just test in etc/HELLO.)

This is a nice way out of the problems implementing what I suggested
above. And I can see it makes sense too.


However it has nothing at all to do with the visual movements when
using the arrow keys. That movement can (and in my opinion should)
still be visual.


>> And that's just the tip
>> of the iceberg.  Without logical-order motion keys, Emacs (and every
>> other editor of similar sophistication) is much less useful.
>
> I think you are referring to the difficulty I suggested above. If not,
> what more problems do you see?
>