Bug 94693 - Cursor up isn't working with a certain kind of wrapping lines
Summary: Cursor up isn't working with a certain kind of wrapping lines
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: HI normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 142361 147104 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-12-08 18:19 UTC by Erik Wasser
Modified: 2007-06-23 15:42 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Fixed (2.42 KB, patch)
2007-05-27 19:55 UTC, Ruud Koolen
Details
A patch for this bug, second version (1.87 KB, patch)
2007-05-27 20:53 UTC, Ruud Koolen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Erik Wasser 2004-12-08 18:19:46 UTC
Version:            (using KDE KDE 3.3.1)
Installed from:    Gentoo Packages
Compiler:          gcc version 3.3.4 20040623 (Gentoo Linux 3.3.4-r1, ssp-3.3.2-2, pie-8.7.6) 
OS:                Linux

Open Kate or open a new window in kate.

Enter some empty lines and go in in the middle of these lines so cursor up could work. B-)

Enter some text (without spaces) like: aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa

Press <TAB>

Enter some text (without spaces) in the same line until the last part wraps around. So your screen looks like this:

1
2
3 aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
> aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
4
5

1)

Your cursor should be at the last 'a' of the second line.

Press 'cursor up'. The cursor jumps to the first 'a' in the second line.

Press 'up' again. With my kate nothing happens here but shouldn't the cursor goes to line 2?

You can leave the line and reproduce this 'feature'.

2)

Click on the last 'a' in the second row. Go down a few times and go up again. Stuck.

3)

Click on the first 'a' in the first row. Go down a few times and go up again. It's working.

It think the bug is related to the fact the kate tries to remember the 'wish-x-coordinate' for the cursor.
Comment 1 Erik Wasser 2004-12-09 16:48:32 UTC
This bug works for 'kwrite' too. I think both are using the same editor components...
Comment 2 Anders Lund 2005-02-18 19:05:09 UTC
I can confirm this using cvs HEAD (the upcoming Kate 2.4)

It's depending on the actual width of the tab, it must be at least two characters I think. So somewhere the width is calculated pr character instead of the real width.
Comment 3 Dominik Haumann 2006-07-02 20:12:41 UTC
Still valid.
Comment 4 Andreas Kling 2006-07-15 19:30:59 UTC
*** Bug 130201 has been marked as a duplicate of this bug. ***
Comment 5 Dominik Haumann 2007-03-04 17:17:28 UTC
*** Bug 142361 has been marked as a duplicate of this bug. ***
Comment 6 Ruud Koolen 2007-05-27 19:55:07 UTC
Created attachment 20703 [details]
Fixed
Comment 7 Ruud Koolen 2007-05-27 20:53:55 UTC
Created attachment 20705 [details]
A patch for this bug, second version

My previous patch only worked when there was only one tab on the wrapped line.
This version also works on lines with multiple tabs.
Comment 8 Dominik Haumann 2007-05-27 22:00:04 UTC
SVN commit 668824 by dhaumann:

fix: tabs in wrapped line broke cursor navigation
Is there a better/faster way? - todo: forward port
Thanks to Ruud Koolen for the patch!

CCMAIL: kwrite-devel@kde.org
BUG: 94693


 M  +5 -5      katerenderer.cpp  
 M  +16 -1     kateviewinternal.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/katerenderer.cpp #668823:668824
@@ -798,6 +798,11 @@
     Q_ASSERT(width);
     x += width;
 
+    // How should tabs be treated when they word-wrap on a print-out?
+    // if startcol != 0, this messes up (then again, word wrapping messes up anyway)
+    if (unicode[z] == QChar('\t'))
+      x -= x % width;
+
     if (unicode[z].isSpace())
     {
       lastWhiteSpace = z+1;
@@ -816,11 +821,6 @@
       }
     }
 
-    // How should tabs be treated when they word-wrap on a print-out?
-    // if startcol != 0, this messes up (then again, word wrapping messes up anyway)
-    if (unicode[z] == QChar('\t'))
-      x -= x % width;
-
     if (x <= maxwidth)
     {
       if (lastWhiteSpace > -1)
--- branches/KDE/3.5/kdelibs/kate/part/kateviewinternal.cpp #668823:668824
@@ -1653,7 +1653,22 @@
 
   if (maxX && range.wrap) {
     QChar lastCharInLine = textLine(range.line)->getChar(range.endCol - 1);
-    maxX -= m_view->renderer()->config()->fontMetrics()->width(lastCharInLine);
+
+    if (lastCharInLine == QChar('\t')) {
+      int lineSize = 0;
+      int lastTabSize = 0;
+      for(int i = range.startCol; i < range.endCol; i++) {
+        if (textLine(range.line)->getChar(i) == QChar('\t')) {
+          lastTabSize = m_view->tabWidth() - (lineSize % m_view->tabWidth());
+          lineSize += lastTabSize;
+        } else {
+          lineSize++;
+        }
+      }
+      maxX -= lastTabSize * m_view->renderer()->spaceWidth();
+    } else {
+      maxX -= m_view->renderer()->config()->fontMetrics()->width(lastCharInLine);
+    }
   }
 
   return maxX;
Comment 9 Dominik Haumann 2007-05-31 00:04:52 UTC
Quick note: The fix is not entirely correct. It does not make it worse, though, so I'll not revert for now.

The problem is, that we always have to iterate through the list and handle the tab characters in order to have the correct maxX position. Is there a better way?
Comment 10 Dominik Haumann 2007-06-23 15:42:13 UTC
*** Bug 147104 has been marked as a duplicate of this bug. ***