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.
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.
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.
I can confirm this. It's like that since a long time already :)
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.
*** Bug 141047 has been marked as a duplicate of this bug. ***
Created attachment 20694 [details] This patch fixes both problems, incorrect brace-matching and not updating the selected lines.
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
*** Bug 137717 has been marked as a duplicate of this bug. ***