Version: 3.1.85 (using 4.1.85 (KDE 4.1.85 (KDE 4.2 Beta2)), compiled sources) Compiler: gcc OS: Linux (x86_64) release 2.6.24-22-generic How to reproduce: * Open a new document * Write foo bar foo bar * Position the cursor in the first line before the foo * Press Ctrl+Del * You get bar foo bar With the cursor in the first line * Now press the down arrow * It gets positioned before the bar of the second line when it should be before the foo of the second line
I can confirm whit: kde 4.2 beta 2 kate 1.1.85
The obvious solution is Index: view/kateviewinternal.cpp =================================================================== --- view/kateviewinternal.cpp (revision 909642) +++ view/kateviewinternal.cpp (working copy) @@ -834,6 +834,7 @@ m_doc->editEnd(); tagRange(selection, true); updateDirty(); + updateCursor(m_cursor, true); } class CalculatingCursor : public KTextEditor::Cursor { Though that is not the CORRECT solution. Here i add my explanation of what i found, someone that knows kate internals should try to fix it: * KateViewInternal::doDeleteWordRight is executed * KateViewInternal::doDeleteWordRight calls editStart that ends up storing in editOldCursor the current cursor (m_cursor) * KateViewInternal::doDeleteWordRight calls wordRight that modifies m_cursor to the end of the new word * KateViewInternal::doDeleteWordRight calls m_view->removeSelectedText(); that ends up calling KateSmartManager::slotTextChanged that modifies the m_cursor of KateViewInternal to be a "null cursor" (starts and ends in the same place) * KateViewInternal::doDeleteWordRight calls KateViewInternal::editEnd that checks if (editOldCursor != m_cursor) to update the cursor and they are the same because of the code in KateSmartManager::slotTextChanged so the cursor is not updated In my opinion KateSmartManager::slotTextChanged touching the m_cursor of KateViewInternal behind his back is a bad thing, but i've no idea on the internals of kate, but if it does, at least the KateViewInternal should be notified or the cursor marked in some way so that the view can update the cursor later.
Ping, any devel around? May i commit the patch even if it's not the optimal solution?
Hm, what about committing to the KDE 4.2 branch to have something working for now? Did you test that it also works with undo and redo correclty?
Sorry for the delay, my HD burnt and i had a hard time going back uptodate. Yeah i've tested it with undo/redo too. About committing only to 4.2 i feel, it'll get lost, what about commiting to both branches but adding a #warning this is probably not optimal, find real solution to trunk?
Agreed...
SVN commit 939378 by aacid: Commit my "probably not real solution" patch to fix Ctrl+Delete losing cursor position Acked by dhaumann BUG: 178379 M +4 -0 kateviewinternal.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=939378
SVN commit 939380 by aacid: Backport r939378 | aacid | 2009-03-14 19:52:14 +0100 (Sat, 14 Mar 2009) | 4 lines Commit my "probably not real solution" patch to fix Ctrl+Delete losing cursor position Acked by dhaumann BUG: 178379 M +4 -0 kateviewinternal.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=939380
*** Bug 187179 has been marked as a duplicate of this bug. ***