On Sun, Feb 06, 2005 at 07:21:58PM +0100, Lars Gullik Bjønnes wrote:
>
> This is making life hard for me.
>
> I just don't understand why the cursor does not change, or am I just
> looking at the wrong cursors.
That is indeed possible.
I don't have the sources handy...
Some of the dispatch functions (all of coordinate/mouse related ones)
work with a temporary cursor. If they want to change the 'real' one,
the have to use 'bv.cursor() = cur' (or similar) explicitly.
I don't think, though, that LyXText::cursorUp() falls into this
category.
> This is the problematic code:
>
> bool LyXText::cursorUp(LCursor & cur)
> {
> Paragraph const & par = cur.paragraph();
> int const row = par.pos2row(cur.pos());
> int const x = cur.targetX();
>
> if (!cur.selection()) {
> lyxerr << BOOST_CURRENT_FUNCTION
> << "Cursor up, no selection" << endl;
>
> int const y = bv_funcs::getPos(cur).y_;
> LCursor old = cur;
> editXY(cur, x, y - par.rows()[row].ascent() - 1);
editXY is usually called from 'mouse related' LFUNs, so it might play a
role here...
> if (cur == old)
> lyxerr << BOOST_CURRENT_FUNCTION
> << " cur and old ARE EQUAL!\n"
> << "old: " << old <<'\n'
> << "cur: " << cur << endl;
>
> return deleteEmptyParagraphMechanism(cur, old);
> }
>
> bool updateNeeded = false;
>
> if (row > 0) {
> updateNeeded |= setCursor(cur, cur.pit(), x2pos(cur.pit(),
> row - 1, x));
> } else if (cur.pit() > 0) {
> --cur.pit();
> updateNeeded |= setCursor(cur, cur.pit(), x2pos(cur.pit(),
> par.rows().size() - 1, x));
> }
>
> cur.x_target() = x;
>
> return updateNeeded;
> }
>
>
> The problem case if when you have a paragraph with text and an open
> inset in it. When you then stand at the top line of the inset, insert
> an extra space between to words and press 'up'. The cursor now moves
> out of the inset and into the line above. Fine and dandy. This is done
> by hte editXY in the code above. However, what is not so fine is that
> old == cur even after this, so DEPM ends up doing nothing and we are
> left with a double-space.
>
> There certainly must be some detail that I am missing.
I think you are on the right track. There are different cursors in the
coordinate based code (the real bufferview.cursor and a temporary one
build from the inset stack at mouse click position). As the use of
'editXY', i.e. a function related to the coordinate based code is here
used as a helper in the 'structure based' code, it's not unreasonable to
expect a bug due to this kind of 'contexxt switch'.
Andre'
