Dov Feldstern wrote:
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...
Quite the contrary, I think we all agree. I have the exact same
understanding as you.
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.
No, I think 2 solutions is enough: logical and visual.
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...
Ouch, are you on the moon already?
Just kidding...
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.
I think it is possible :-)
The problem is simple really and I think you are misleading because you
focus on the inset. When you think about it, entering or leaving an
inset should not be special; continuous navigation is possible when LTR
snippet is embedded in an RTL text: the cursor goes in the opposite
direction and then "jumps" to the end of the snippet before going again
in the visual direction.
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.
See above.
Abdel.
