Stefan Schimanski wrote:
I think this version of the patch is ready to commit. I have tested it
on many examples and think the behavior is as it should be (up to some
minor points which can and should be addressed later). Below you find
some explanation of what the patch does and these issues. If you haven't
tried it out, please do so and send a answer here, I don't feel good to
commit it if I am the only one who tried it, and then RC1 is broken
because of that.
@Abdel: Could you take a look and try it? I think there is no difference
to the behavior of the patch you tried. But one never knows.
@José: Can I commit it if I get some feedback? When will you tag RC1?
* So, ripped off the FINISHED_UP/DOWN logic. I believe this was done
because the UP/DOWN handlers had a "half global" logic, so they were
trying to move the cursor up/down by taking the whole cursor in
consideration, i.e. a LFUNs handled by a math inset would pop off slices
from the cursor to move up/down until it's empty. That contradicts the
whole dispatch mechanism which sends the LFUN to any inset in the cursor
anyway.
I have cleaned that up that now in such a way that every up/down
dispatch handler only tries to move the cursor with local knowledge, and
fails (i.e. set the LFUN undispatched) otherwise. So if a handler
doesn't know what to do, he just ignores the LFUN and the following
cursor slices will get their chance to fulfill the up/down LFUN.
As far as I see there is no need for the FINISHED_UP/DOWN logic here
anymore because every dispatch handler can just keep the LFUN
undispatched and everything magically works in the following handlers.
* I took a brief look at some cursor bugs in Buzilla: at least 2754,
2894, 3243 seem to be fixed, maybe others as well. I still have a few
things to be improved, but they are not critical and can be done later.
* The most prominent one are jumps from text into math. The jump are
implemented by calling editXY in the line below with a y value in the
first pixel line of the math inset. I am not really sure what the
behaviour should be now. Imagine big parenthesis
\left( \somethinghigh abcde \right)
If your cursor is placed above the abcde, you probably would expect to
jump into the abcde. But the editXY does not recognize this if y is too
small because the point on screen is not inside abcde. Instead the
cursor jump in front of the \left(. In the old code some arbitrary value
was added to the y value which often made it work as expected. But
depending on line height, font settings etc., sometimes the y value then
was too big, so the cursor jumped in one line further.
* Another point for improvement is InsetTabular. If you are in the last
row and press cursor down, the cursor jumps behind the tabular. In fact
this behavior is hard coded in the tabular code. So I guess there is
some reason to do that. I don't like it. The down key should move the
cursor down. This could easily be changed to behave in the latter way.
But I fear that people depend on the old behavior.
Stefan
Hmmm... there are some minor changes in the behavior of LyX due to your
patches. For example, in a paragraph which spans multiple lines: if you
move back (left in LTR) from the first position in the line, you used to
be placed immediately after the last letter on the previous line. Now,
you are placed one space after that. Going in the other direction,
though, that space "doesn't exist": you move immediately from after the
last letter to the new line. So going across that boundary, you can move
one space forward and two spaces backwards and get back to the same
place. I think the old behavior (where that space doesn't exist in
either direction) makes more sense (because just like any other space,
you need *one* cursor movement to get from just before the first letter
in the second word to just after the last letter in the first word, and
vice versa).
I don't know that this really matters very much, but something is a
little off...
Dov
