Performance issues with treesitter when there is entry with :PROPERTIES:

[WhiteBlackGoose]

Describe the bug

Adding a new entry under first level header gets incredibly slow (up to 1s lag). E. g.

...
* Header
<caret>

In place of type *. It will lag for 500ms or so.

When I do it, it tries to redraw the whole thing on the first asterisk inserted. It does it wrong, because on the first asterisk it redraws everything into the color of the first level header. Especially noticeable when everything is expanded.

Steps to reproduce

1. Open file
2. Go to header "Blog"
3. Type * (asterisk)
4. It redraws the whole thing into pink and lags for a second

Expected behavior

Adding entries should be instant

Emacs functionality

No response

Minimal init.lua

Used the provided minimal_init.lua (no my configuration). link

Screenshots and recordings

No response

OS / Distro

NixOS

Neovim version/commit

0.9-dev 5c9bf0ea74aa9297227242f17058a9f0c4c0c115

Additional context

Thank you, this is an amazing plugin

[WhiteBlackGoose]

And it throws a lot of errors when I try to use it without TS. Very frustrating :( (in my file, lags can be 2-3 seconds)

[WhiteBlackGoose]

Workaround: insert space at the same time as asterisks

norm = { noremap = true, silent = true }
vim.api.nvim_set_keymap('n', 'c1', 'i*<space>', norm)
vim.api.nvim_set_keymap('n', 'c2', 'i**<space>', norm)
vim.api.nvim_set_keymap('n', 'c3', 'i***<space>', norm)
vim.api.nvim_set_keymap('n', 'c4', 'i****<space>', norm)

This works instantly. However, it's key that the space is inserted too. Otherwise, the same bug hits.

[jgollenz]

I can confirm this. This looks like a treesitter issue to me. I could narrow it down to

* foo
    SCHEDULED: <2023-03-09 Thu>
    :PROPERTIES:
    :END:
|
* bar
  :PROPERTIES:
  :END:

(pipe represents the cursor)

Inserting the * at this point should result in an error that is not detected in this case. I'll have to do some further investigation. Another workaround would be to not insert new headings manually but with <leader>oih from the previous heading (or its body).

edit: personally this never happened to me because when I hit Enter after * Blog|, nvim auto-indents and adds to white-spaces.

[WhiteBlackGoose]

The tree built by the treesitter also breaks often. I couldn't reproduce it yet, except when you type a few asterisks on a few line but not a space. But I feel like sometimes, headings without contents are interpreted compelteley wrong. E. g. folding in this text normally works as expected.

Expanded:

* Heading
** Another 1
** Another 2
** Another 3
** Another 4

Collapsed:

* Heading

Sometimes though the collapsed looks like this:

* Heading
** Another 3
** Another 4

[WhiteBlackGoose]

folding breaks too

Here's a correct tree and incorrect folding

[rybaz]

Glad I'm not the only one having this issue. I have org files that previously worked fine not folding at all until I edit content underneath a heading, then it folds on itself.

[WhiteBlackGoose]

@rybaz you can use my fork (#523), folding works perfectly there

[jgollenz]

@WhiteBlackGoose @rybaz let's keep this issue on topic and move discussions about folding here

[kristijanhusak]

Similar issue was reported here #625. It should be resolved on latest master + :TSUpdate.