Add dynamic query for coloring n-depth headlines

[qaptoR]

rather than define queries for set n=8 depth headlines, set autocommand that searches for stars and uses length of stars text to determine depth using modulo operation to wrap for number of color groups (hardcoded still at 8, but would be nice to define any number of groups easily in the futur

[kristijanhusak]

Thanks for the PR!
Before we proceed with this, I'm curious, what is the max depth that you need usually?
I do understand that 8 might be low, but going over 15 or 20 just seems like a strange usage.

[qaptoR]

The reason is mainly threefold:

1. As a programmer I prefer solutions to things that solve the general cases. So rather than an exhaustive list I try to attack the root.

2. I was initially just going to double the number because I thought the same as you that it wasn't likely that I would need more. But then I realized that there may someday be case where I need more, and furthermore, that I am not the only user and there may be others who do have a regular use-case.
   a. for instance there is a feature in gptel (a chatgpt emacs package) where you can carry on an infinitely branching conversation with the ai, because wherever in the tree you are when you run the command it us the path to the root as the conversation history. So infinite depth would be useful. Currently there is not feature in the gpt plugins I use for neovim, but I am on a crusade to establish parity with emacs for all of the features that I loved about doom emacs.

3. To keep parity with emacs. It wraps color infinitely.

[kristijanhusak]

It wraps color infinitely

After which numbers colors start to repeat?

I'm ok solving this, but not in this way.
I'd prefer introducing a custom predicate like we have for org-is-todo-keyword, and have it figure out if the headline is a correct level. Then we would have these 8 colors, and they would repeat, the same way you did here.

[qaptoR]

is it possible in the predicate language of treesitter to define a query that applies a modulo operation on the length of the query? I saw that the predicate could be a regex pattern, but I could not figure out how to define a dynamic query

[kristijanhusak]

Yes, something like this should work (didn' tested it though):

"highlights.scm
(headline (stars) @_stars (#org-is-headline-level? @_stars "1")) @org.headline.level1
(headline (stars) @_stars (#org-is-headline-level? @_stars "2")) @org.headline.level2
"etc

  vim.treesitter.query.add_predicate('org-is-headline-level?', function(match, _, source, predicate)
    ---@type TSNode
    local node = match[predicate[2]]
    local level = tonumber(match[predicate[3]])
    if not node then
      return false
    end
    local _, _, _, node_end_col = node:range()
    return node_end_col % level == 0
  end, { force = true })

[qaptoR]

wow, that is super powerful! I didn't realize that you could define your own predicate like that! I thought we were limited to the ones listed in the treesitter doc pages.

This totally changes the way I'm going to consider using treesitter in the future.

[kristijanhusak]

Yes, there are several custom ones here https://github.com/nvim-orgmode/orgmode/blob/master/lua/orgmode/config/init.lua?plain=1#L342

You can adapt this PR to use the custom predicate similar to the one I posted in a previous comment.

[qaptoR]

would you like me to apply that new predicate to this PR and test? or will you put it in your own commit, and I should close this one?

[kristijanhusak]

You can go ahead and update this PR.

[qaptoR]

Okay, sorry of the many force pushes. had to track down that this part tonumber(match[predicate[3]]) had to be changed to tonumber(predicate[3]).
So cool that this works though. makes me way more confident to work with treesitter in the future.

[kristijanhusak]

Okay, sorry of the many force pushes. had to track down that this part tonumber(match[predicate[3]]) had to be changed to tonumber(predicate[3]).

No worries, I wrote it that way in my example without testing.
Looks good now, thanks!

[qaptoR]

No worries, I wrote it that way in my example without testing.

My bad, I wasn't implying a failure on your part, just that I didn't fully understand how the arguments to the predicate handler worked, despite reading the documentation several times. It was basically trial and error for me, and I felt I needed to explain because when the github actions run each time I force push I assume that it is costing some amount of compute time for the project.

I really appreciate that you wrote the solution to begin with, as it has launched my understanding of how to work with treesitter.