[bwanders]

This PR proposes a fix for the tree-sitter queries for setext-style headers in markdown files.

The setext header queries in tags.scm for the language-gfm package were incorrectly structured, which led to only ATX headers being listed in the symbols-view. With a small correction to the setext queries, so the nesting structure matches that produced by the grammar, the setext headers now correctly match, and are also listed.

[savetheclocktower]

Can you give me some sample Markdown that illustrates the problem? setext-style headings seem to work just fine for me in Markdown files; the heading titles show up in the symbols-view palette along with the atx-style headings.

[bwanders]

(Edit: fixed an error in the ATX demo to match header levels with the setext version. Edit 2: corrected version name from "Atom" to "Pulsar", I was still asleep apparently...)

Sure thing.

These observations are based on a Pulsar 1.131.3 (on the windows portable version.)

The following symbol providers are active (as per symbols-view's show active providers command):

• ctags provided by symbol-provider-ctags
• Tree-sitter provided by symbol-provider-tree-sitter

ATX

ATX headers work as expected:

# Lorem

Blah blah.

## Ipsum

More Blah.

Producing the following:

Setext

Setext version:

Lorem
=====

Blah blah.

Ipsum
-----

More Blah.

Produces the following:

[savetheclocktower]

Yeah, I can reproduce that! No idea why my experiments last night weren't producing the same result.

Thanks; I'll make sure this gets into the upcoming release!

[savetheclocktower]

I’ve verified that this fixes the issue for me locally.

The previous query structure is invalid on its face — it described the underline node as being outside of the setext_heading node. But if it were truly impossible, Tree-sitter would’ve thrown an error when we tried to instantiate the query — which happens when the grammar first loads, I think, but certainly no later than the first time we ask for symbols.

The fact that this sort of query wasn’t automatically invalid could therefore be a (very minor) bug in the tree-sitter-markdown parser. Or it could just be Tree-sitter understanding that such a strange sequence of nodes is theoretically possible in certain scenarios where error-handling comes into play.

But no matter — this PR fixes it! In the course of testing this, though, I accidentally discovered that, even when a grammar’s tags.scm is invalid, we don’t ever seem to surface an error. The only obvious symptom would be that symbol-provider-tree-sitter would fail to suggest any symbols.

So we’re swallowing an error somewhere. I should make sure that we at least log a warning to the devtools console in these situations. I’ll create an issue for that so it doesn’t get lost.

Thanks so much for the contribution!

[savetheclocktower]

This change cannot possibly affect the CI status, since only a tags.scm file has changed; so I'm landing this without waiting for a green button.

(We certainly should have unit tests for tags.scm, just like we've got some for highlights.scm; but creating the infrastructure for that is its own task!)