Andre Poenitz wrote:
On Fri, May 04, 2007 at 04:07:18PM +0300, Dov Feldstern wrote:
Andre Poenitz wrote:
The LFUNs are named wrongly. It should be 'LFUN_CHAR_LEFT', since that's
what's supposed to happen on screen. This could be mapped to
LFUN_CHAR_BACKWARD denepding on isRTL() for 'logical' movement.
Andre'
I'm not sure that this is correct: precisely in the situations we're
discussing here, of LTR embedded in RTL, we want the LEFT key to keep
moving forward, even if forward means right...
Oh. Do we?
I am not using RTL myself, so be patient. You mean there are situations
where a 'native RTL user' would expect the cursor to move visually to
the right when he presses the <Right> key?
Yes, that's what Dov means, he's given some nice explanation there:
http://bugzilla.lyx.org/show_bug.cgi?id=3551 *
Personally I'd prefer screen oriented navigation. WRT to selection
problems with embedded LTR text, I think we should not try to be clever
and select the full LTR snippets (the same as we do with insets for
example). The logic of RTL snippets embedded in an LTR text should of
course be the same.
Abdel.
* Repeated here:
In an RTL paragraph, the LEFT key moves logically forward (even in LTR text
embedded in the paragraph), and RIGHT moves logically backwards. This is
correct, and is called "logical" cursor movement (as opposed to
"visual", see
below *).
The bugs:
(1) This behavior should also extend to the cursor's movement inside insets
which appear inside the paragraph (in other words, whether LEFT moves
forwards
or backwards should be determined by the *outer* paragraph's language),
however
currently it doesn't.
(2) This behavior should also extend to movement into and out of an inset,
regardless of it's direction (in other words, in an RTL paragraph where LEFT
moves logically forward, then when positioned logically before the
inset, LEFT
should enter it, and when positioned logically at the end of the inset, LEFT
should move to the position logically *after* the inset). Current
behavior is
not like this (I'm not sure yet exactly why).
(3) When the cursor is positioned logically before an inset, for some
reason the
cursor visually moves to the *LTR* beginning of the inset, whereas it
should, in
my opinion, be placed at the *RTL* beginning of the inset (to understand the
problem, try selecting the space before (to the right of) the inset in the
attached file; strange, right? Now try deleting the selection: the
selection was
correct, it's visual appearance is not.
I'm not sure if all of the problems are inter-dependent or not. (3) is a
regression, in 1.3.X the behavior was correct.
See bug #904, which deals specifically with math insets.
See also bug #1965, which may be related. I think that at least some of the
problems I mention are related to the 'boundary' stuff, which I don't fully
understand yet.
* Just a note regarding "visual" cursor movement, once I've mentioned it.
In this mode, LEFT always moves left and RIGHT always moves right. LyX
does not
currently support this mode. We could implement it, too, and let the
user decide
which kind of movement she prefers (many applications provide this choice).
However, there are a few issues to keep in mind before implementing this:
1) In this mode, a selection could actually contain logically non-contiguous
text (e.g.: "a-bc F+ED ghi", where lowercase is LTR, uppercase is RTL,
selection
visually starts at '-' and ends at '+', meaning that the selected text
is 'bc '
and 'F', which are not contiguous logically.)
2) This is quite complicated to implement if the embedded section spans
multiple
lines (suddenly the logical movement is dependent on the visual appearance).
