On 8 May 2010 00:34, Avi Hayoun iceman400@gmail.com wrote:
i am moving this to a new thread as Enrico requested. this is a continuation of sorts of the discussion in my introduction thread.
i've been trying to track down this problem: "...both in geany 0.18 and in the trunk version, when 2 matching braces are separated by a 3rd brace in a string or in a comment, the correct pair are colored as matching. however, if there is a closing brace in a comment or string and an opening brace is added before the comment/string, the brace will not auto-close..."
the problem is caused by GetEndStyled() returning (current_brace_position-1), which is smaller than the current position when there is an unmatched brace in a following comment/string, and so (position > GetEndStyled()) || (styAtPos == styBrace) on line 1575 in geany/scintilla/Document.cxx is returning true, and as a result braces in strings/comments are not ignored in the method BraceMatch(). what this means is that in this case:
{ char * some_string = "some text } some more";
the 2 braces are considered matched by BraceMatch() (the method returns the position of the closing brace as a match for the opening brace when called from auto_close_chars() in geany/src/editor.c), when in reality the shouldn't be. as mentioned in the bug description, this means that the first brace in the above example will not get autoclosed. this same behavior occurs when there is a closing brace in comments.
when there is no closing brace in a string/comment, GetEndStyled() returns the last position in the document, which means that in those cases, BraceMatch() will only return a matching brace is the styles of the 2 braces match (correct behavior).
i've been trying to figure out what is causing the endStyled variable in the Document class in scintilla to be set differently when there is a closing brace in a comment/string, but i'm stumped. it is possible that when an opening brace is added to the document, endStyled is always set to (current_brace_position-1), but that it is then reset to the last position in the document when the closing brace is automatically added. this means that i've been looking for the problem in the wrong place, but i'm not sure where else to look. if there is anyone here that has a better understanding of how scintilla handles styles or if any of this is sounding familiar to anyone, i'd be grateful for any insight into the matter.
something that might be relevant to this: while debugging this, i noticed that auto-closed braces have a style code of 10, a brace in a string has a style code of 6, which i think are both correct after looking at the style codes for C in geany/scintilla/include/Scintilla.iface. however, an opening brace that is incorrectly matched by a brace in a string/comment has a style of 0. i think this is a symptom of the underlying bug that is causing the miss-matching of the braces, and not a bug in it's own right. on the other hand, as with endStyled, this may be the correct behavior for a single, unmatched brace...
hope you ll have a blast of a weekend. regards, avi
The problem appears to be that Geany is calling auto_close_chars which uses sci_find_matching_brace from a SCN_CHARADDED notification. But sci_find_matching_brace depends on styling and the documentation for SCN_CHARADDED says " This notification is sent before the character has been styled so processing that depends on styling should instead be performed in the SCN_UPDATEUI notification."
You will notice that the unmatched brace is styled correctly as unmatched. This is because editor_highlight_brace which also uses sci_find_matching_brace is called from the SCN_UPDATEUI notification.
Cheers Lex
Geany-devel mailing list Geany-devel@uvena.de http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel