Asciidoc symbols panel cannot display Level 5 Section Title

[jack6th]

geany v.138 on Windows

= Document Title (Level 0)
== Level 1 Section Title
=== Level 2 Section Title
==== Level 3 Section Title
===== Level 4 Section Title
====== Level 5 Section Title
== Another Level 1 Section Title

Level 5 Section Title is lost in symbols panel.

[elextr]

@techee something changed when it was upstreamed, the parser accepts level 5 here and it has a letter here but its not in the enum here? Whats the comment about, does it matter not being in the enum, or does Geany just ignore letter u?

And whats "cork" (a tree bark stopper in a wine bottle or a place in Ireland is all I know)?

[techee]

@techee something changed when it was upstreamed, the parser accepts level 5 here and it has a letter here but its not in the enum here? Whats the comment about, does it matter not being in the enum, or does Geany just ignore letter u?

Note the difference in numbering in uctags and in what @jack6th sent as an example - level 5 in uctags is 5 equal signs while in the example above it is 6 equal signs because it starts from level 0. The n_same variable in the parser is named confusingly because it's always the number of = +1 and this 1 is then subtracted so the code n_same <= 6 actually checks for level 5.

Basically right now ===== level with 5 = is the deepest level supported by the parser. Would probably be trivial to increase this limit though.

And whats "cork" (a tree bark stopper in a wine bottle or a place in Ireland is all I know)?

It's the place in Ireland ;-).

No, well, I have no idea about where the name came from but when a parser uses "cork", it can do things like createTag(my_tag, parent_tag); and ctags takes care of correct generation of scope for my_tag (inside parent_tag and if parent_tag is also nested, it adds all the parents). Here this parser just uses the stack for parents directly by calling nestingLevelsPush(nestingLevels, r);.

[elextr]

The n_same variable in the parser is named confusingly because it's always the number of = +1 and this 1 is then subtracted

No its named right, its the count of the number of characters the same, it needs one subtracted because C is 0 based indexing, but having 0 characters the same is hard to detect as markup :-)

with 5 = is the deepest level supported by the parser.

Although this compares <= 6 whereas the original did <= 5 probably lucky it didn't overflow the kinds array. Thats what I mean something changed somewhere. But it looks like not enough changed, maybe someone started and never finished the change.

Would probably be trivial to increase this limit though.

Probably should be, current Asciidoc has the levels as the OP copied from its docs.

Historically IIRC (its a looooong time ago) it was originally designed to mainly handle sections with the heading underlined by a line of the same length, of which there are only four levels, but those are now correctly deprecated in Asciidoc since they don't work with variable width fonts, and are shaky with Asian double width characters, and really bad with other Unicode characters of zero, half, and one and a half width. That would explain the comment here.

[techee]

No its named right, its the count of the number of characters the same, it needs one subtracted because C is 0 based indexing, but having 0 characters the same is hard to detect as markup :-)

Yep, I got this one wrong.

Although this compares <= 6 whereas the original did <= 5 probably lucky it didn't overflow the kinds array. Thats what I mean something changed somewhere. But it looks like not enough changed, maybe someone started and never finished the change.

Notice, though, that the original only supported level 4 sections (i.e. 5 =), see

geany/tagmanager/ctags/asciidoc.c

Line 42 in f227076

{ TRUE, 's', "struct", "level4sections" }

while the current ctags parser supports level 5 sections (i.e. 6 =), see

geany/ctags/parsers/asciidoc.c

Line 58 in ae1f499

{ true, 'u', "l5subsection", "level 5 sections" },

The n_same variable comparison is against the number of = which is +1 than the index to the table. So I think this is correct.

Historically IIRC (its a looooong time ago) it was originally designed to mainly handle sections with the heading underlined by a line of the same length, of which there are only four levels, but those are now correctly deprecated in Asciidoc since they don't work with variable width fonts, and are shaky with Asian double width characters, and really bad with other Unicode characters of zero, half, and one and a half width. That would explain the comment here.

I actually based the new markdown parser on the asciidoc parser with the same limitation of the number of sections so this one could be increased too.

[elextr]

while the current ctags parser supports level 5 sections (i.e. 6 =), see

except that as the OP said, it doesn't, or it does and Geany doesn't, but anyway level 5 doesn't show in the symbols.

Does it matter that the enum here does not go to level 5?

[elextr]

Or is this the culprit in T-T-T-(takes brave pills)-Tagmanager ;-)

[techee]

Yeah, we also don't have the kind mapped here (tm_tag_undef_t means unmapped):

geany/src/tagmanager/tm_parser.c

Line 837 in ae1f499

{'u', tm_tag_undef_t}, //l5subsection

I'll prepare a patch.

[techee]

Does it matter that the enum here does not go to level 5?

This is probably "correct" but extremely ugly. Those K_CHAPTER up to K_LEVEL4SECTION aren't used anywhere in the code, they are there just do define SECTION_COUNT which is used for

geany/ctags/parsers/asciidoc.c

Line 62 in ae1f499

static char kindchars[SECTION_COUNT]={ '=', '-', '~', '^', '+' };

and thanks to SECTION_COUNT (and missing K_LEVEL5SECTION) the following K_ANCHOR has the right index too. This thing would really deserve some cleanup.