Stefan Schimanski wrote:
Type a long line with no spaces (aaaaaa....) until the line breaks
because it's too wide, and continue a bit. Then type a space, and then
bbbbb... until the bbbb moves to a new line.
Recall, there is no space in the middle of the aaaa, but there is a
space between aaaa and bbbb.
So, starting to move right from the beginning: when we reach the
position before the last 'a' on the first line, moving right once more
should move us immediately to the next line (there's no space there;
moving right should move us to the next character). OTOH, when we
reach the last 'a' on the second line, moving right again should move
us to *after* the last 'a' (which is before the space), and only
moving right again should move us to the next line.
Ok, not sure if it's really better. But maybe yes... matter of taste.
Yes, I guess so. But there should be a difference between the two
situations; and that *is* the way LyX used to work (at least in 1.3.X).
If later versions don't behave that way, it's probably unintentional,
just another part of the fact that we stopped understanding what the
boundary_ really does...
The logic I use is this: to get from pos a to pos b should take the same
number of keystrokes, whether or not it's across a line break.
But yes, it is a matter of taste, I guess.
Why should that correct? The condition will never be true because no
character is newline and separator at the same time.
Hmm... right... maybe some of those should be "or"s. But obviously
they're not really necessary at all... That's what I tried saying a few
days ago, but I didn't then understand why...
But the question is valid when we should do this boundary game. You
suggest we never play it. What about insets (e.g. with display math)?
With letters you also suggest not to do it, makes sense maybe. Is there
any other case left than insets?
Well, there's the bidi situation, that's one place we use it.
There's also a separate case, but it doesn't manifest itself in cursor
movement (in terms of affecting the number of keystrokes between positions):
if I'm between emph and normal text, and type a character, should it be
emph or not? Well, if I'm coming from the emph to the border, then it
should be emph; and if I'm coming from the non-emph, it should be
non-emph. I think that that's what the setCursorFont is supposed to be
doing. Same goes for languages. (Both situations are captured by the
"font" concept in LyX).
Stefan
Dov
