Still hijacking this PR for the moment:
Oops. Normally all we'd have to do is properly fill `extensionFields.scopeIndex`, like that: ``` diff --git a/ctags/parsers/rest.c b/ctags/parsers/rest.c index 1a9dd2e22..a192babf3 100644 --- a/ctags/parsers/rest.c +++ b/ctags/parsers/rest.c @@ -34,11 +34,19 @@ typedef enum { SECTION_COUNT } restKind;
+static scopeSeparator RestScopeSeparators [] = { + { KIND_WILDCARD, ":::" } +}; + static kindOption RestKinds[] = { - { true, 'n', "namespace", "chapters"}, - { true, 'm', "member", "sections" }, - { true, 'd', "macro", "subsections" }, - { true, 'v', "variable", "subsubsections" } + { true, 'n', "namespace", "chapters", + ATTACH_SEPARATORS(RestScopeSeparators) }, + { true, 'm', "member", "sections", + ATTACH_SEPARATORS(RestScopeSeparators) }, + { true, 'd', "macro", "subsections", + ATTACH_SEPARATORS(RestScopeSeparators) }, + { true, 'v', "variable", "subsubsections", + ATTACH_SEPARATORS(RestScopeSeparators) } };
static char kindchars[SECTION_COUNT]; @@ -49,7 +57,7 @@ static NestingLevels *nestingLevels = NULL; * FUNCTION DEFINITIONS */
-static void popNestingLevelToKind(const int kind) +static NestingLevel *getNestingLevel(const int kind) { NestingLevel *nl; tagEntryInfo *e; @@ -63,14 +71,14 @@ static void popNestingLevelToKind(const int kind) else break; } + return nl; }
static void makeRestTag (const vString* const name, const int kind) { + const NestingLevel *nl = getNestingLevel (kind); int r = CORK_NIL;
- popNestingLevelToKind(kind); - if (vStringLength (name) > 0) { tagEntryInfo e; @@ -79,6 +87,9 @@ static void makeRestTag (const vString* const name, const int kind)
e.lineNumber--; /* we want the line before the '---' underline chars */
+ if (nl) + e.extensionFields.scopeIndex = nl->corkIndex; + r = makeTagEntry (&e); } nestingLevelsPush(nestingLevels, r); ```
Unfortunately, although this results in correct scope being emitted, somehow the symbols tree fails to handle nesting when a separator occurs. I didn't dig yet, but it seems like a bug in Geany. To whether it makes sense to emit more than one scope level for parsers like reST… well, IMO it does; the challenge here is that scope separation is recorded with specific characters in the scope string, and "languages" like reST allow any character in a tag, making this a little fragile. We're using ":::" right now, and ETX (ASCII 03) for Asciidoc and Txt2Tags. The latter two seem less fragile, but still not fully error proof. So in the end, even though I don't like it too much, it might indeed male sense to only keep one level in the scope here.