Wrong painting of cursor after newline

[ps@…]

1. launch new file, set enumerate environment, put some equation, write some

word, go out of equation, hit ctrl+return

2. very often cursor remains at the same line and must type some character to

get correctly rendered on the new line. can't get some reliable recipe, but it
happens also with normal text.

lyx 1.6 beta4

[Uwe Stöhr]

I can reproduce it:

• create a new file
• insert an enumerate environment
• insert an equation
• press the right arrow key to jump out of the equation
• press Ctrl-Return

Result: The cursor remains at the same line and must type some character to
get correctly rendered on the new line.

[Vincent van Ravesteijn]

The problem is that cur.boundary is incorrectly set when leaving the math inset.

InsetMathNest.cpp 636--637:

if movement failed, then finish forward or backwards as necessary

The LFUN that is dispatched is either LFUN_FINISHED_RIGHT or LEFT, while the
command says forward or backward.

After dispatching LFUN_FINISHED_RIGHT we end up in Cursor::posVisRight

Cursor.cpp 514--518:
set the boundary to true in two situations:
1. if new_pos is now lastpos (which means that we're moving
right to the end of an LTR chunk which is at the end of an
RTL paragraph);

At this moment the boundary member is set because new_pos==lastpos(), but I
don't see why ?

[Vincent van Ravesteijn]

just a guess

[Dov Feldstern]

No, the suggested patch breaks visual cursor movement in math.

The whole idea of "visual mode" movement is that in bidirectional text, the
mapping left/right <-> forward/backward is not straightforward (by pressing
"right" we sometimes need to move logically forward, and sometimes logically
backwards; conversely, logical "forward" movement is sometimes achieved by
moving right, other times by moving left). That's why the command is talking
about moving forward or backwards, but is actually "implementing" that movement
by moving right or left.

There may still be a bug in my original code though, I'm looking it over now
with respect to this issue.

[Dov Feldstern]

Before delving into the code, two more observations:

1. it's not really necessary to do this in an enumerate environment, this can be

reproduced just as easily in standard environment.

2. it only happens with Ctrl-Enter, not with a real Enter. (Which explains (1)

--- the reason this was noticed in enumerate, is because that's where Ctrl-Enter
is often used instead of Enter; in standard text you'd just use Enter).

Item (2) is interesting, I think that the direction to solving this issue is
figuring out what the difference between Ctrl-Enter and Enter is.

[Vincent van Ravesteijn]

In the case of Ctrl-Enter, the cursor is painted either at the beginning of
the next row or at the end of the current row. This depends on the state of
cur.boundary_. Normally, cur.boundary_ will never be true at the location of a
newline. So, the only difference between Enter and Ctrl-Enter is that the
latter reveals the bug that the cur.boundary_ is incorrectly set.

Exiting the math inset sets cur.boundary_, although I don't have any clue why.

The comment I quoted in comment 2 (Cursor.cpp 514--518) is not very helpful.
Sure, new_pos is equal to lastpos, but I can't see that this means that we are
at the end of an RTL paragraph.

[Dov Feldstern]

patch which fixes bug noticed by Vincent, though it only covers up real problem of #5061

[Dov Feldstern]

Yes, Vincent is correct: both the code and the comment he pointed out in comment
2 are incorrect, the above patch fixes this.

However, #5061 still exists when boundary is set to true for a correct reason;
for example, try this recipe:

• create a new file
• insert an equation
• press the right arrow key to jump out of the equation
• press Ctrl-Return
• switch the language to an RTL language (e.g., Hebrew)

Result: The cursor jumps back up to the same line as the newline, and must type
some character to get correctly rendered on the new line.

I think the correct solution is that even when boundary==true, the cursor should
*not* be painted after the previous character, if the previous character is
Ctrl-Enter or Ctrl-Shift-Enter. I can't think of *any* situation where we would
legitimately want to paint the cursor *after* such a character.

[Dov Feldstern]

Committed patch from comment 7 (​http://www.lyx.org/trac/changeset/27225).

Issue from comment 8 is still open, we're discussing how to solve it.

[Dov Feldstern]

A few patches fixing further manifestations of this issue (Vincent was right,
BTW --- after looking over the code, I agree that the problem is that boundary
should not be set to true in these cases):

​http://permalink.gmane.org/gmane.editors.lyx.devel/113505
​http://permalink.gmane.org/gmane.editors.lyx.devel/113506
​http://permalink.gmane.org/gmane.editors.lyx.devel/113507

[Juergen Spitzmueller]

changing target to 1.6.3.

[Juergen Spitzmueller]

What shall we do with this? Dov, could you provide a complete patch for branch? (1.6.5 rather than 1.6.4 probably).

[Vincent van Ravesteijn]

The status was that I proposed to split the boundary() member into two. One for line breaking and one for RTL stuff. Then the logic would become slightly easier. I guess that that means that it's my honor to also implement it. ;-).

Or we could apply the patches by Dov. IIRC they worked well.

[Vincent van Ravesteijn]

Fixed in trunk at r30765.

[Juergen Spitzmueller]

OK as well.

[Vincent van Ravesteijn]

Fixed in branch at r31757.

[Vincent van Ravesteijn]

Another fix at r31791. The cursor jumped in front of an Inset at the next row.

[Juergen Spitzmueller]

LyX 1.6.5 ante portas.