Abdelrazak Younes wrote:
Dov Feldstern wrote:
Anyhow, back to the point:
Basically, within the framework of logical movement, it's a question
of whether we prefer the cursor to get stuck at insets, but to move
"correctly" (i.e., the way the arrows point) inside them; or we prefer
that the cursor *not* get stuck, but that means that the cursor inside
the insets will move opposite to where the arrows point.
We definitely prefer that the cursor does not get stuck.
I just want to clarify --- when I say "stuck", it's not really "stuck
and you can't get out"; rather, it's stuck in the sense that by just
holding one key down, the cursor starts jumping back and forth into and
out of the inset, instead of moving ahead. However, by careful
manipulation there (now press right, now press left, ...), it *is*
possible to keep moving. I find this disrupting, but apparently not
everyone agrees with me...
I'm starting to think that perhaps we could offer the user a choice:
there would be a box within the languages section for "Bidi Cursor
movement", which would allow the options "Logical (insets as
standalone)", "Logical (insets as embedded)" and "Visual" if/when we add it.
Technically, this would be a cinch to implement: the only difference is
whether to use "bottom().paragraph()" or "innerParagraph()", and by
unifying all the places where we deal with this, along the lines of what
I do in the latest version of my patch, we'd only need to do this in one
place. In C++, we could probably even do it using some polymorphic
mechanism, if efficiency were to become an issue...
And then there's the heuristic I mentioned yesterday: short insets
should behave according to my patch (you want to easily traverse them),
longer insets behave as they do today (you want to be able to edit them
easily, traversing them is not so much of an issue, since they're so big
anyhow...).
I think I'm going crazy...!
When/if we
implement the 'visual' mode, there would be no problem. In 'logical'
mode, this means that we need to be careful when we reach the beginning
of the end of an inset. Inside an inset, the cursor navigation should
exclusively depend on the current language. Math insets are special
because they always are LTR.
If you mean "careful manipulation" by the user --- then it's already
like that, as explained above. If you mean, by us programmers, such that
the user will be able to do it *without* careful manipulation --- I
don't think it's possible.
What was bothering me last night was: how come we appear to be able to
do it in the math insets, but not in other insets? Until I realized that
we're not doing it in math insets: in math insets, we *are* allowing the
cursor to move opposite to the direction of the arrows (if it's in an
RTL paragraph), which is exactly what we're trying to avoid elsewhere.
But that's the tradeoff: easily moving in and out comes at the price of
moving backwards inside (or vice versa).
If we prefer the former, my patch should be applied. If the latter, it
should not.
I do prefer the former, as I've already explained, I find it more
disruptive when the cursor gets stuck than when the cursor moves in
the direction opposite to where the arrows point.
We agree on the conclusion, just not on the method to get there ;-)
So how do we decide? If you like, I can send a questionnaire to the
user's list (and to everyone I know who uses LyX in Hebrew), and we'll
see what they say. But what do we do if it's a tie?
I don't think many users will choose a cursor that will get stucked in
an inset. I propose that we investigate a tiny bit more my solution
descibred above (special case on beginning and end of an inset). If
there is no way to implement that easily, then we will go for your
solution instead. Deal?
Deal. :) Though I need clarification as to what exactly your idea is, as
explained above.
Abdel.
