Test cases should be added, and somebody (@elextr :wink: ) should actually test the Asciidoc part. You can view, comment on, or merge this pull request online at:
https://github.com/geany/geany/pull/2019
-- Commit Summary --
* Fix reST and Asciidoc parser scope
-- File Changes --
M ctags/parsers/asciidoc.c (28) M ctags/parsers/rest.c (25) M src/tagmanager/tm_parser.c (4)
-- Patch Links --
https://github.com/geany/geany/pull/2019.patch https://github.com/geany/geany/pull/2019.diff
@b4n doesn't work, level one sections group under the document heading like a document overview, but level 2 and 3 and 4 levels are still grouped as levels, and symbol name is (for example) `Asciidocxx Design[3]File Organisation[3]Front[3]Main` where `[3]` is the square symbol with 0003 in it.
Why can't we just put the four lines back in?
@b4n from uctags `asciidoc.c`
``` if (parent && (parent->kindIndex < kind)) { /* * This doesn't use Cork, but in this case I think this is better, * because Cork would record the scopes of all parents in the chain * which is weird for text section identifiers, and also this is * what the rst.c reStructuredText parser does. */ e.extensionFields.scopeKindIndex = parent->kindIndex; e.extensionFields.scopeName = parent->name; } ```
Hence my question, why are you doing something different, why not just put the original back since its in upstream?
@b4n this isn't needed see [here](https://github.com/geany/geany/pull/2018#issuecomment-448164371)
I fixed this PR (Asciidoc was also listed as not having full scope)
Hence my question, why are you doing something different, why not just put the original back since its in upstream?
Isn't the purpose of this whole exercise to sync with upstream?
It is, but I'm not sure upstream itself shouldn't be changed. The most important reason why this is a problem is that with this behavior the parser output is semantically different from other parsers -- not to mention that it's then harder to distinguish children of identically-named sections.
But yeah, the PR here is just one solution, and we can and probably should use upstream's, changed or not.
techee commented on this pull request.
Since upstream parsers seem to work fine, I would prefer those for now and if there's something to be improved, make the changes upstream and later import it to Geany.
The most important reason why this is a problem is that with this behavior the parser output is semantically different from other parsers
Correct, its intended to display as a document overview, same for rest. But thats not what uctags is designed for, but it seems to be able to include sufficient information to work correctly.
not to mention that it's then harder to distinguish children of identically-named sections.
Not sure what you mean by this? AFAICT identically named sections display correctly [see](https://pastebin.geany.org/JOm69/).
Correct, its intended to display as a document overview, same for rest. But thats not what uctags is designed for, but it seems to be able to include sufficient information to work correctly.
It's not a matter of how it's displayed in Overview (which is our business to do it right in Geany) but the problem is that the scope field in the tag file isn't complete and only contains its immediate parent (instead of full scope like all other parsers).
Not sure what you mean by this? AFAICT identically named sections display correctly see.
Try this: ``` = foo
== foo
=== foo
== foo ```
I agree with @b4n the current implementation isn't the best but I'd prefer not introducing a diff in Geany now and rather fix it upstream.
I agree with @b4n the current implementation isn't the best
Ok, your example is fairly pathological, its not likely in real documents (not impossible, but not likely), and quite frankly the parser breaks way too often on real documents before something like that needs to be worried about (I can say that since I wrote it) Examples like mine with repeated headings in different sections are common but work ok.
but I'd prefer not introducing a diff in Geany now and rather fix it upstream.
Totally agree, the whole point of the exercise is to align with upstream, so lets get to that point (for those parsers where we can eg not c.c) so things get easier.
I agree with @b4n the current implementation isn't the best
And if @b4n wants a challenge!! Asciidoc is going to allow unlimited section level nesting soon so how ill uctags and Geany handle that?
Obsoleted by the merge of #2018.
Closed #2019.
github-comments@lists.geany.org