*Word* inside paragraph recognized as tag

[yochem]

This is probably one of Vimdoc's endless quirks, but I haven't seen it being mentioned in an issue here so I thought I would mention it.

Words surrounded by a * or starting with one are parsed as tag node. I think this is a bug, and as far as I'm aware, tags can only appear (1) as last node of a line, or (2) as node that is only followed by other tag nodes in the same line. Would it make sense to add this restriction to the vimdoc parser?

Here's a list of 'wrong' tag nodes in Nvim's current docs:

• editing.txt:1320 Files (*)\t*\n" on other platforms, so that the user can still access any
• usr_22.txt:34 " Sort sequence: [\/]$,\.h$,\.c$,\.cpp$,*,\.info$,\.swp$,\.o$\.obj$,\.bak$ ~
• editing.txt:1319 may want to add "All Files (*.*)\t*\n" as the final filter on Windows or "All
• usr_11.txt:129 Vim recognizes files with the pattern *.s[uvw][a-z] as swap files.
• luvref.txt:409 Note: Luvit will implicitly call uv.run() after loading user
• luvref.txt:444 Note: Be prepared to handle the ENOSYS error; it means the
• usr_02.txt:431: At the top of the help screen, there is the notation *help.txt*. This name
• syntax.txt:2622 the patterns *printcap*, or *termcap*, you must put additional patterns
• syntax.txt:2622 the patterns *printcap*, or *termcap*, you must put additional patterns
• helphelp.txt:340 To define a help tag, place the name between asterisks (*tag-name*). The

[clason]

Probably not; it's better to edit the docs to make clear these are verbatim or code snippets (wrap in quotes or backticks, respectively).

(Working around vimdoc's endless -- and undocumented -- quirks is a quixotic goal. Instead, we should tighten up the format for our own use and enforce it strictly. Note also that long-term, we want to move the help parser into a Lua module.)

[yochem]

Alright! Maybe I'll create a PR for the Vim-owned help files on their repo. For now, I'll fix the luvref.txt one as I believe that's the only Nvim-owned helpfile from the list above.

[clason]

I don't see the luvref tags, tho. Please make sure you look at master. (Also, the goal is to generate that file from our vendored meta annotations, so probably not worth putting much effort in.)

[clason]

And we ignore the Vim user manual (usr_*); the remaining files should be ERROR-free -- unless a recent vim-patch regressed that.

(The syntax.txt tags are certainly an upstream error; they were probably intended to be tags, forgetting that this doesn't work.)

[yochem]

Also, the goal is to generate that file from our vendored meta annotations, so probably not worth putting much effort in.

Ah alright. I tried to find if the file was generated but thought it was not. I'll drop that commit then from #34255.

I don't see the luvref tags, tho.

I think that is because currently :helptags does not rely on TS yet: it manually parses the help files. This means the *Note* parts don't appear as tag, but :InspectTree shows a tag node.

Context: I was experimenting with replacing the implementation of :helptags with a TS-based approach.

[justinmk]

I was experimenting with replacing the implementation of :helptags with a TS-based approach.

did you see:

• build: generate helptags without running "nvim" binary neovim#34186

[yochem]

Yes, that's how I came up with the idea. I commented on that one asking if the TS parser would be available without nvim binary. If it's not, then it won't solve the problem that PR aims to solve.

I was planning to create a PR that replaces :helptags with a TS-based implementation and let core team decide if it's desired.

[clason]

TS parser would be available without nvim binary

It is, but without an nvim binary, it's useless

[yochem]

It is, but without an nvim binary, it's useless

I thought so. However, it was not yet clear to me if it could be used from "nlua0".