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

[Question] Is it possible to optionally include the leading space #12

Open
akinsho opened this issue Jul 13, 2022 · 2 comments
Open

[Question] Is it possible to optionally include the leading space #12

akinsho opened this issue Jul 13, 2022 · 2 comments

Comments

@akinsho
Copy link

akinsho commented Jul 13, 2022

I'm trying to achieve the equivalent of the highlighting provided by something like https://github.com/folke/todo-comments.nvim or the following emacs screenshot.

One thing I haven't been able to figure out how to do it is to match the preceding whitespace for a tag if there is any.

image

This doesn't seem to be part of the actual comment i.e. this parser I don't think covers it, and I'm also unable to use #offset! to extend the range of the injection so I guess my question is, is this currently possible with a query (as far as you can see) or would it require this parser to be able to include it?

@stsewd
Copy link
Owner

stsewd commented Jul 15, 2022

Hi, the offset directive currently only works with queries for injections, I thought there was an issue tracking this on neovim, but the closes to this is neovim/neovim#16032.

Once the offset directive is supported on highlights queries, you should be able to write a query and/or directive to include the surrounding spaces.

Another solution would be for the parser to expose the "whitespace" nodes

const WHITE_SPACE = choice(" ", "\t", "\v", "\f");
, but I haven't seen any other parser to that.

@akinsho
Copy link
Author

akinsho commented Jul 18, 2022

Thanks for the response @stsewd and linking the nvim issue. I guess wondering re. the whitespace issue since it appears that the capture/match (not sure the right term) can be extended to include whitespace if it can optionally also contain a capture that includes the whitespace, so it all stays the same for everyone and matches what it currently does but then also there is a larger node like (tag_with_space) or a sane name that includes the leading space. That way you don't have to expose the white space explicitly, unless this somehow forces you to do that

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

No branches or pull requests

2 participants