fix: mark '|' as word

[clason]

No description provided.

[clason]

@justinmk this removes all but two errors (one of which is trivial to fix on our side) but leaves a bunch of (~70) MISSING nodes that I can't suppress in this test (and which are often related to incorrect highlighting). What's the appetite for fixing up our docs once and for all?

(The biggest issue -- which is a huge issue -- is that Vim docs use literal backticks all over the place, which is an unresolvable conflict with codespan. Not sure how to fix that in the grammar. In the files, you can work around this by putting such input in quotes, but that will be inconsistent since all other input is not quoted.)

(Possibly ignoring all of usr_* as not our problem and not worth it?)

[justinmk]

Vim docs use literal backticks all over the place

I haven't looked much at the usr_ docs but I haven't seen these widespread problems... our docs gen asserts zero errors

In the files, you can work around this by putting such input in quotes

for "literal backticks" that seems fine. how many cases are there of that actually

[clason]

I haven't looked much at the usr_ docs but I haven't seen these widespread problems... our docs gen asserts zero errors

No, it only asserts zero _generateerrors; there are parsing errors that don't break docgen so are not caught in our CI. This test here is much more strict about ensuring a correct parse (even if the error may be recoverable). For example, many of theMISSING` nodes here actually tied to wrong highlighting (because the missing node is inserted in the wrong place).

for "literal backticks" that seems fine. how many cases are there of that actually

About 8 files (after my nvim PR is merged), some of those with potentially many occurrences. So it's not a minor effort (and risk of reintroducing them when we port vim patches, although current patches are unlikely to involve marks).

[justinmk]

❤️

[clason]

Windows failure parsing the corpus is consistent; my guess is that some regex in the grammar are not Windows-safe. Since I can't deal with that and it looks unrelated to the changes here, I'm disabling the Windows job. Someone with access to Windows and tree-sitter needs to investigate, fix, and re-enable; that someone is not me, but they can ping me if they need help.

[justinmk]

my guess is that some regex in the grammar are not Windows-safe.

How?

[clason]

I don't know, that's the point. But we've had issues involving that on other parsers in the past, the errors seem to revolve around * e.g. in codeblocks, and it's the only thing I can come up with that would explain the Windows-only failure.

[clason]

Could also be an issue with the tree-sitter parse command or the action; the changes here pass nvim-treesitter CI at least.