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

Cannot highlight parentheses in real-time #2

Open
lzlcs opened this issue Jul 4, 2023 · 14 comments
Open

Cannot highlight parentheses in real-time #2

lzlcs opened this issue Jul 4, 2023 · 14 comments
Assignees
Labels
bug Something isn't working

Comments

@lzlcs
Copy link

lzlcs commented Jul 4, 2023

Neovim version

0.9.1

Language affected

scheme

Query

No response

Strategy

No response

Description

The same as [this](https://github.com/HiPhish/nvim-ts-rainbow2/issues/52)
@lzlcs lzlcs added the bug Something isn't working label Jul 4, 2023
@ReubenM
Copy link

ReubenM commented Jul 11, 2023

Seems related to another bug I reported on: lukas-reineke/indent-blankline.nvim#555

Blankline gets scope information from treesitter, but it's like it's working off of stale cached info and the scope returned is messed up once an edit is made. ":edit" also fixes things there as well. However Blankline is also fixed with ":update", but that doesn't seem to have effect for rainbow-delimiters.

It seems like something to do with cache invalidation or re-scanning to sync the treesitter state is not working as expected for external plugins using treesitter that were not an issue with the depreciated treesitter modules.

mathieuroblin added a commit to mathieuroblin/.dotfiles that referenced this issue Jul 14, 2023
A bug in treesitter: HiPhish/rainbow-delimiters.nvim#2
makes it annoying at the moment. Will revert this later.
@def-SpaceWar
Copy link

The same thing is happening for me. In both Racket and Clojure when using nvim-surround, parenthesis don't update color until another delimiter type is modified, such as another parenthesis. It is not limited to the Lisp language family, and happens with all other delimiters (tags included).

@HiPhish
Copy link
Owner

HiPhish commented Aug 27, 2023

It this still a problem on the current master?

@alexmozaidze
Copy link
Contributor

This problem is still present, but only with global strategy.

@HiPhish
Copy link
Owner

HiPhish commented Jan 28, 2024

This problem is still present, but only with global strategy.

Do you have Tree-sitter highlighting enabled? Call vim.treesitter.start() in your buffer and tell me whether real-time highlighting works.

For the technical background, there is a callback registered which will re-apply rainbow highlighting whenever the tree structure changes. However, this callback is only called if general Tree-sitter highlighting is enabled for that buffer. And yes, it has to be enabled per buffer. I was not aware of this because by nvim-treesitter configuration does it implicitly.

@alexmozaidze
Copy link
Contributor

alexmozaidze commented Feb 2, 2024

I think the issue has been resolved on the latest plugin version, since I didn't encounter it in quite a while. At least for me.

@TheTrueWhiteOwl
Copy link

This issue has not been resolved!!! I have the exact same issue: the highlighting does not update in real time.

It starts working as intended and updates in real time when I call vim.treesitter.start(). It also seems to update once if I run :edit

I am on rainbow-delimiters v0.4.0 on nvim v0.9.5

Hope this can be fixed!!

@alexmozaidze
Copy link
Contributor

Yeah, it hasn't been resolved. I noticed that it can be triggered by visual selecting a region with brackets and deleting and then undoing the deletion.

@TheTrueWhiteOwl
Copy link

TheTrueWhiteOwl commented May 22, 2024

For anyone looking for a temporary 'fix' for this problem, the following autocommand seems to work:

-- HACK: temporary fix to ensure rainbow delimiters are highlighted in real-time
vim.api.nvim_create_autocmd(
   "BufRead",
   {
      desc = "Ensure treesitter is initialized???",
      callback = function()
         -- if this fails then it means no parser is available for current buffer
         if pcall(vim.treesitter.start) then
            vim.treesitter.start()
         end
      end,
   }
)

@HiPhish
Copy link
Owner

HiPhish commented May 29, 2024

To everyone who is wondering why nothing has happened: I still cannot replicate the problem, so I cannot "fix" it either. That's why this issue is still lingering on.

@TheTrueWhiteOwl I don't understand this autocommand. You call vim.treesitter.start twice, but why?

@TheTrueWhiteOwl
Copy link

TheTrueWhiteOwl commented May 29, 2024

@HiPhish I am really embarrassed about the fact that I published the code like that publicly and I must apologize for the confusion...

You see, I wrote that temporary fix at something like 1:00 AM in the morning. The only important part of that autocmd was the vim.treesitter.start() since it ensures treesitter is working properly and the parentheses are highlighted in real-time. However, that raises an error when called inside a buffer where no parser for that language is available, so I placed it inside a pcall: hence the pcall(vim.treesiter.start).

At the time I also decided to try running other pieces of code inside buffers parsed with treesitter and since the pcall already served as a kind of way to check if I was inside such a buffer I just used it in an if statement. However later I removed those extra function calls and when I saw that the if statement was empty I just put the vim.treesitter.start() inside again...

I feel like an absolute fool especially due to the confusion I caused... Here is the autocmd without the duplicate call.

-- HACK: temporary fix to ensure rainbow delimiters are highlighted in real-time
vim.api.nvim_create_autocmd(
   "BufRead",
   {
      desc = "Ensure treesitter is initialized???",
      callback = function()
         -- if this fails then it means no parser is available for current buffer
         pcall(vim.treesitter.start)
      end,
   }
)

On another note, I think it is important to also consider the possibility that this issue does not stem from the rainbow-delimiters extension, but rather from nvim-treesitter itself, since the issue is fixed by calling vim.treesitter.start()?

@HiPhish
Copy link
Owner

HiPhish commented May 29, 2024

@TheTrueWhiteOwl Haha, it's OK, no need to aplogize this hard.

If the problem is indeed the lack of vim.treesitter.start(), then that give me an idea: I have nvim-treesitter/nvim-treesitter installed and set up. I think calling the setup function installs an autocommand similar to to the hack. Do any of the people who do not get live updated have it installed and set up as well?

@def-SpaceWar
Copy link

It's been fixed for me (IDK when I use kakoune now) but I just felt like contributing at some point an update fixed it for my neovim.

@def-SpaceWar
Copy link

I checked like exactly right now. ^

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

6 participants