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
