Summary: | [PATCH] Problem in cursor placing after doing Ctrl+Delete | ||
---|---|---|---|
Product: | [Applications] kate | Reporter: | Albert Astals Cid <aacid> |
Component: | general | Assignee: | KWrite Developers <kwrite-bugs-null> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | kari.argillander, pawelsalawa |
Priority: | NOR | ||
Version: | unspecified | ||
Target Milestone: | --- | ||
Platform: | unspecified | ||
OS: | Linux | ||
Latest Commit: | Version Fixed In: |
Description
Albert Astals Cid
2008-12-21 16:50:21 UTC
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. *** |