>Okay, there are actually two separate issues here: > >(1) boundary is incorrectly set to true in this case (my bug, correctly
>diagnosed, but incorrectly fixed, by Vincent); The attached patch fixes >it. If nobody has objections to it, I'll check it in tomorrow evening. > >This is good enough to fix #5061 in the normal case. Good. >(2) 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. Why is it correct that the boundary is true in this case ? I probably haven't thought enough about RTL-LTR boundaries, but either - you don't want the cursor to be painted on the row of the newline, which means boundary should be false, or - you want to paint the cursor before the newline, but then the cur.pos() is wrong. Just to understand. Assume we have aaaaa|bbbbb, with a = LTR, b = RTL and | the cursor. Is the boundary member now used to indicate whether the cursor is in the LTR or in the RTL part ? Then in the case you described we have two valid positions: aaaaaaa|n bbbbb and aaaaaaan |bbbbb In this last example, boundary can only be false to indicate that it is in the RTL part. If boundary would be true, then cur.pos() is also wrong, because it should point to the location before the newline (as in the first position) >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. Opinions? That is true, but I still think it only reveals the incorrect setting of the boundary member. And I don't like specific code that will correct only for newlines. >Dov > >BTW, Enrico --- thanks for checking svn blame (or are you using git?) >for this! --- I don't think I would have noticed this issue otherwise... I should have warned you when I stumbled across RTL stuff... Vincent
