GNOME Bugzilla – Bug 547151
Matching Brackets Highlighter ignores code semantics
Last modified: 2010-10-25 05:54:30 UTC
Please describe the problem: gedit matching bracket highlighting feature (enabled/disabled through Edit menu > Preferences > View tab > Highlight Matching Bracket tickbox), does not care whether the opening and closing brackets are inside quoted strings (e.g. in case of a C source file) or inside comment blocks. Steps to reproduce: 1. Open gedit 2. Create a new empty document and change the highlighting mode to C (through View menu > Highlight Mode > Sources > C) 3. Type in the following C code into the editor: // This is a lil comment which has a left square bracket ( '[' ) in it int main(void) { printf("]"); } 4. Move the typing cursor over the opening square brackets on the first line Actual results: When moving the cursor over the opening square brackets in the comment line, it is matched and highlighted with the closing square brackets inside the quoted string which resides inside the printf() function. Expected results: Bracket highlighting should be confined to meaningful blocks of code (in case of source files). For instance, brackets inside a comment block should only be matched with other brackets within the same comment block. Similarly, brackets inside quoted strings should be matched only to other brackets within the same quoted string. Does this happen every time? Yes Other information:
I confirm this bug. Happens even with < and > in a simple C-program as the following snippet: if (i<10) { printf("Too less"); } else if { (i>20) printf("Too high"); } else { printf("Accepted"); } When the cursor is placed at the <, it highlights the > in the next statement. Tested in gedit (version - 2.22.3) Using GtkSourceView (version - 2.2.2) On ArchLinux (Updated to date)
*** Bug 551942 has been marked as a duplicate of this bug. ***
I think this is a pretty serious bug in certain circumstances. It makes using certain languages that rely heavily on nesting (like Scheme) virtually unusable. I have been trying to fix this bug myself but without much luck. I have tracked down it's emergence though: Fixed: revision 178 Re-introduced: revision 1380 Any chance we can get this triaged or at least confirmed? It's easy to check and it is in every version.
These are revisions of gtksourceview by the way. > > Fixed: revision 178 > > Re-introduced: revision 1380 The relevant code is the function iter_has_syntax_tag (which was functional and now is just a stub) in gtksourcebuffer.c. Is there a way to change what program a bug is reported for? Because this is definitely a gtksourceview problem. Sorry for the confusion.
It is a gtksourceview bug, and bugzilla agrees, it's the "Product" in the top right corner. Don't worry about it. Interesting question is who is going to fix it and when...
*** Bug 580293 has been marked as a duplicate of this bug. ***
*** Bug 584736 has been marked as a duplicate of this bug. ***
This issue has now been fixed. With the recent support for context classes, we can now easily determine contexts such as strings and comments. I just patched it up now that the set of classes applied to the start character have to match the set of classes applied to the end character. This means that it will now correctly skip comments or strings that are in between two matching brackets. It also stops searching when the set of classes that apply to the current search position is smaller than the set of classes that apply to the starting bracket (indicating that it goes outside of the meaningful scope of the starting bracket).
*** Bug 607857 has been marked as a duplicate of this bug. ***
Has this been fixed already? I can't reproduce it.
@jp - The bug was marked Resolved and Fixed months ago. Check comment 8 in this thread for details, its wonderful.
ooooh hehehe ok i thought so, because it was working for me already hehe XP