[Geany-devel] brace-balancing

[Lex Trotman]

On 8 May 2010 00:34, Avi Hayoun <iceman400 at 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 at uvena.de
> http://lists.uvena.de/cgi-bin/mailman/listinfo/geany-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.geany.org/pipermail/devel/attachments/20100508/c7289bb5/attachment.html>