Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

feature: distinguish comment payload from comment markers #244

Open
1 task done
BrunoMSantos opened this issue Dec 26, 2024 · 0 comments
Open
1 task done

feature: distinguish comment payload from comment markers #244

BrunoMSantos opened this issue Dec 26, 2024 · 0 comments

Comments

@BrunoMSantos
Copy link

BrunoMSantos commented Dec 26, 2024

Did you check the tree-sitter docs?

Is your feature request related to a problem? Please describe.

I'm trying to inject other parsers onto C/C++ comments where multi-line context is crucial for correct highlight, namely rst.

Yet I (1) found no way of creating a capture that takes only the relevant parts of the comment and I suspect it is not possible to do so (not sure though) and (2) it's way harder and prone to difficulties than for (e.g.) Python where one has '(expression_statement (string ...))`.

A common injection for C comments is doxygen which is already meant to parse C/C++ comments, but not rst. Closest I got was something like:

 ((comment) @injection.content                              
   (#lua-match? @injection.content "^/[*][*]<?[^*].*[*]/$") 
   (#offset! @injection.content 0 3 0 -2)                   
   (#set! injection.language "rst"))                        

Which kind of works, but will fail for comments like this, as an example:

/**
 * Some title <- seen as a bullet point due to the leading `*` being part of the capture
 * ==========
 */

Describe the solution you'd like

A capture that sensibly excludes comment leads, ends and prefixes, and yields the 'payload' only. I'm assuming this is possible of course, which maybe it isn't and maybe I actually need a new rst parser just for this.

Describe alternatives you've considered

Somehow recreating this with a lot of regexes, but I have yet to figure out how and, again, I'm not sure this is even possible one way or another without a specific parser from my little knowledge of how tree sitter works.

Additional context

This alternative to Doxygen: https://github.com/jnikula/hawkmoth

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

1 participant