b4n commented on this pull request.
> @@ -2289,6 +2290,32 @@ static gint get_fold_header_after(ScintillaObject
> *sci, gint line)
}
+/* returns the line after following all brace match for @brace on @line */
+static gint resolve_matching_braces(ScintillaObject *sci, gint line, gint
brace)
+{
+ gint pos = sci_get_position_from_line(sci, line);
+ gint line_end = sci_get_line_end_position(sci, line);
+ gint lexer = sci_get_lexer(sci);
+
+ for (; pos < line_end; pos++) {
@elextr
> does this need to be a separate function?
No, I initially wrote it inside `get_current_tag_name()`'s body, but it seemed
like a contained enough logic to be worth wrapping in a logical container (the
function). I can un-split it if you want, but it seemed slightly less nice to
me there. But admittedly I'm an advocate of splitting up logical units when
the reader can then see it as that logical unit ("this search for the line on
which unmatched parentheses on `@line` are all matched") and can avoid caring
about the implementation, or find a implementation issue in the logic there
rather than in the context of a whole other set of stuff -- but yes, I do think
there is such thing as over-splitting, too (basically when it ends up in split
things that don't have a defined goal by themselves).
> its style dependent, because C doesn't require it to be on the same line.
> Maybe should look for the first open parens not assume its on the same line.
That's a good point, but would be slightly more subtle to fix. Though maybe
not so much, just check each fold level between the tag and the containing one
and see if it matches parentheses matching, and skip it if so. I'll give it a
look.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/geany/geany/pull/1280
