Bug 139578 - Code folding screws up highlighting
Summary: Code folding screws up highlighting
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Applications
Component: folding (show other bugs)
Version: unspecified
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 137717 141047 (view as bug list)
Depends on:
Blocks:
 
Reported: 2007-01-04 02:27 UTC by Stef Louwers
Modified: 2007-05-28 04:03 UTC (History)
4 users (show)

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


Attachments
Testcase with instructions (1.76 KB, text/x-csrc)
2007-01-05 15:39 UTC, Thomas Friedrichsmeier
Details
This patch fixes both problems, incorrect brace-matching and not updating the selected lines. (2.40 KB, patch)
2007-05-25 10:52 UTC, Ruud Koolen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Stef Louwers 2007-01-04 02:27:10 UTC
Version:           unknown (using KDE 3.5.5, Debian Package 4:3.5.5a.dfsg.1-2 (testing/unstable))
Compiler:          Target: i486-linux-gnu
OS:                Linux (i686) release 2.6.14.rldesktop

When any code is folded, the highlighting of my php syntax starts to do weird things. Curly braces matching near the cursor fails, and sometimes the cursor disappears altogether (while still being functional). A note of interest is that these problems happen only in parts of the file *after* the folded code.
Comment 1 Thomas Friedrichsmeier 2007-01-05 15:39:13 UTC
Created attachment 19111 [details]
Testcase with instructions

Attaching a testcase to show two sorts of wierd behavior after folded regions:
Failure to highlight matching curly braces, and failure to clear selection
markers.

Instructions on reproducing the bugs are enclosed in the testcase. The testcase
also contains some observations on when the bugs go away.

From a lay-persons perspective, this seems like a problem in updating the view.
Perhaps most interestingly, using the scroll-wheel (as described in the
testcase) seems to update the view properly.
Comment 2 Thomas Friedrichsmeier 2007-01-05 15:44:28 UTC
Additional note: The problem(s) is/are not constrained to PHP, but also work with different hightlighting definitions, including at least C, C++, and R Script, suggesting the highlighting definition is definitely not to blame.

When using the testcase, of course you will have to set C highlighting, in order to get any code-folding markers at all.
Comment 3 Dominik Haumann 2007-01-05 16:55:53 UTC
I can confirm this. It's like that since a long time already :)
Comment 4 Alan Prescott 2007-01-12 10:44:20 UTC
With PHP and Python - using mouse to highlight a block of text which stays highlighted/selected even when the cursor is clicked elsewhere in the text.
Plus if the cursor is clicked somewhere inside the highlighted block then just that one line becomes unhighlighted.
Can confirm that this appears to affect only the area after the fold.
Comment 5 Dominik Haumann 2007-02-02 09:36:41 UTC
*** Bug 141047 has been marked as a duplicate of this bug. ***
Comment 6 Ruud Koolen 2007-05-25 10:52:48 UTC
Created attachment 20694 [details]
This patch fixes both problems, incorrect brace-matching and not updating the selected lines.
Comment 7 Dominik Haumann 2007-05-27 00:31:46 UTC
SVN commit 668607 by dhaumann:

fix bug: Code folding screws up highlighting
Converting from/to virtual cursors was wrong.
Patch by: Ruud Koolen - Thanks a lot!
BUG: 139578


 M  +8 -8      kateview.cpp  
 M  +4 -4      kateviewinternal.cpp  


--- branches/KDE/3.5/kdelibs/kate/part/kateview.cpp #668606:668607
@@ -1521,32 +1521,32 @@
       // We have to tag the whole lot if
       // 1) we have a selection, and:
       //  a) it's new; or
-      tagLines(selectStart, selectEnd);
+      tagLines(selectStart, selectEnd, true);
 
     } else if (blockSelectionMode() && (oldSelectStart.col() != selectStart.col() || oldSelectEnd.col() != selectEnd.col())) {
       //  b) we're in block selection mode and the columns have changed
-      tagLines(selectStart, selectEnd);
-      tagLines(oldSelectStart, oldSelectEnd);
+      tagLines(selectStart, selectEnd, true);
+      tagLines(oldSelectStart, oldSelectEnd, true);
 
     } else {
       if (oldSelectStart != selectStart) {
         if (oldSelectStart < selectStart)
-          tagLines(oldSelectStart, selectStart);
+          tagLines(oldSelectStart, selectStart, true);
         else
-          tagLines(selectStart, oldSelectStart);
+          tagLines(selectStart, oldSelectStart, true);
       }
 
       if (oldSelectEnd != selectEnd) {
         if (oldSelectEnd < selectEnd)
-          tagLines(oldSelectEnd, selectEnd);
+          tagLines(oldSelectEnd, selectEnd, true);
         else
-          tagLines(selectEnd, oldSelectEnd);
+          tagLines(selectEnd, oldSelectEnd, true);
       }
     }
 
   } else {
     // No more selection, clean up
-    tagLines(oldSelectStart, oldSelectEnd);
+    tagLines(oldSelectStart, oldSelectEnd, true);
   }
 }
 
--- branches/KDE/3.5/kdelibs/kate/part/kateviewinternal.cpp #668606:668607
@@ -2231,11 +2231,11 @@
       // @@ Do this only when cursor near start/end.
       if( bmStart > bmEnd )
       {
-        tagLines(bmEnd, bmStart, true);
+        tagLines(bmEnd, bmStart);
       }
       else
       {
-        tagLines(bmStart, bmEnd, true);
+        tagLines(bmStart, bmEnd);
       }
     }
     else
@@ -2258,11 +2258,11 @@
       // @@ Do this only when cursor near start/end.
       if( bmStart > bmEnd )
       {
-        tagLines(bmEnd, bmStart, true);
+        tagLines(bmEnd, bmStart);
       }
       else
       {
-        tagLines(bmStart, bmEnd, true);
+        tagLines(bmStart, bmEnd);
       }
     }
     else
Comment 8 Dominik Haumann 2007-05-28 04:03:54 UTC
*** Bug 137717 has been marked as a duplicate of this bug. ***