Changes of tasks affect previous task, not current

[gerazov]

Are you using "tree-sitter" branch?

Yes

Describe the bug

When doing cit or <leader>ois on the current task, actually changes the previous task. This used to work fine before.

Steps to reproduce

Add two tasks and try updating the second one.

Expected behavior

The second one updates.

Emacs functionality

No response

Screenshots and recordings

No response

OS / Distro

Manjaro Linux

Neovim version/commit

0.5

Additional context

No response

[gerazov]

Ok I restarted Vim (actually it hanged and I had to close the tmux pane and open it in a new pane) and this now works ...

Maybe it's something with my vim.

[kristijanhusak]

I'm assuming tree-sitter got messed up somehow and didn't parse things properly. Next time it happens, try force editing the file with :e! and see if it happens. If it does, let me know and I'll take a look.

[gerazov]

There's something fishy that happens but didn't bother posting.

These things happen on both branches but let's focus on tree-sitter :slightly_smiling_face:

For example when first opening vim and an org file I get good coloring:

But <Tab> folding on the tasks doesn't work - e.g. task 1 gives error:

E5108: Error executing lua [string ":lua"]:1: Vim(normal):E490: No fold found

Also <S-Tab> cycles through the views in the messages, but no folding actually happens.

If I reload the config (init.vim), the text is now parsed but wrongly colored:

Folding still doesn't work, but now <S-Tab> does work.

And after cycling views, now folding with <Tab> actually works as expected :sweat_smile:

It might be some config thing ...

[kristijanhusak]

Folding is not really well tested, since I'm not using it myself. It definitely needs more care. Why are you reloading your init.vim? In my previous comment I meant to reload the org file by editing it via :e!. Todo keyword colors are colored through treesitter, but added manually to the queries, since they can be dynamic. There might be a situation where those are not sourced, usually when something errors out. I need to figure out a way how to source them no matter if something errors out or not.

[gerazov]

I was just commenting what makes folding work. :e! doesn't help for folding.

I'll try :e! for the original bug :wink:

[kristijanhusak]

I moved adding todo highlights first thing on init. Not sure if that will help though.

[gerazov]

no, I have the same behavior ..

[kristijanhusak]

Ok. Please file a separate issue for this, with reproducible steps, so I can keep track of it.

[gerazov]

Ok so :e! does fix the original bug :clap:

[kristijanhusak]

@gerazov ok, but you can still reproduce the bug? If yes, let's reopen this.

[gerazov]

Well I can't figure out what triggers it ...

[kristijanhusak]

@gerazov are you able to reproduce this each time? I'm not able to reproduce it:

Only difference is that I'm not using org bullets plugin and using fast access for todo states, but that shouldn't affect it. Do you maybe have some custom mappings?

[gerazov]

It keeps reappearing. I'm using fast access as well. Tried turning off the bullets - doesn't help.

Found it! It happens when I duplicate a line using:

nnoremap <A-J> :copy .<CR>

And also when moving a line downwards with:

nnoremap <A-j> :m .+1<CR>

[kristijanhusak]

I can't manage to reproduce it.

If you can reproduce it 100% of the time, can you please install https://github.com/nvim-treesitter/playground, and right before the bug happens (before you trigger cit on the 2nd gif), open up the tree view with :TSPlaygroundToggle and give me the content of the tree buffer? Also, it would be great to provide minimal init.lua/vim, maybe it's some of the other configurations that I'm not aware of. Also, i see on both gifs that you add todo to the item, then remove it, and then copy/move and get the bug. Are you doing undo here or changing the todo state to empty state? I'm suspecting that undo potentially causing some issues here.

[gerazov]

Skipping the undo doesn't help, btw how do you clear the todo with fast access?

Here's what treesitter does:

[kristijanhusak]

btw how do you clear the todo with fast access?

When you get the prompt press the space.

Can you do the same thing with the opened playground, but once you switch the task places, write the file and edit it with :e!? I want to see what happens with the tree. Seems like it doesn't figure out the update and treats both sections as one once you switch them. I want to see if write/edit would refresh that. Sorry for bothering you that much, but I can't reproduce it myself so it's hard to debug.

[sempie]

I get this behavior as well. Almost any attempted manipulation to the cursor line actually manipulates the previous line.

e! does allow me to make one proper manipulation to the current line, but then I must save and use :e! again.

Using treesitter branch and org-bullets.

[kristijanhusak]

@sempie do you maybe have reproducible steps that I can try? Also, what neovim version are you using? Same question for @gerazov. I tried to reproduce with org bullets but it doesn't happen for me. I tried 0.5.1 and latest master and everything seems fine. I see from gif that treesitter misbehaves, I just can't get it into that state.

[kristijanhusak]

@gerazov @sempie are you sure you are having the latest ts parser build? Try doing :TSUpdate and see if it still happens.

[sempie]

I ran :TSUpdate, using neovim 0.5.1 and still get this behavior.

My steps are:

1. opening a file that looks like this:

   * heading 1
   * heading 2
   * heading 3

2. have cursor on heading 2, type oit and create new TODO heading below heading 2

3. exit insert mode and type >> to demote the TODO heading

4. heading 2 gets demoted under heading 1

Some relevant config from init.vim:

"----------------------------------------------
" Org-Mode
"----------------------------------------------
lua << EOF
local parser_config = require "nvim-treesitter.parsers".get_parser_configs()
parser_config.org = {
  install_info = {
    url = 'https://github.com/milisims/tree-sitter-org',
    revision = 'main',
    files = {'src/parser.c', 'src/scanner.cc'},
  },
  filetype = 'org',
}

require'nvim-treesitter.configs'.setup {
  -- If TS highlights are not enabled at all, or disabled via `disable` prop, highlighting will fallback to default Vim syntax highlighting
  highlight = {
    enable = true,
    disable = {'org'}, -- Remove this to use TS highlighter for some of the highlights (Experimental)
    additional_vim_regex_highlighting = {'org'}, -- Required since TS highlighter doesn't support all syntax features (conceal)
  },
  ensure_installed = {'org'}, -- Or run :TSUpdate org
}

require('orgmode').setup({
  org_agenda_files = {'~/Sync/orgs/*'},
  org_default_notes_file = '~/Sync/orgs/refile.org',
})
EOF

[kristijanhusak]

@sempie thanks! Finally I managed to reproduce it. Looking at it now.

[kristijanhusak]

@sempie can you try removing disable = {'org'} from the treesitter highlight config just to see if that makes it work? For me it works when ts highlights are not disabled for org. I assume it works because parsing is done more often and it updates TS tree more often.

[sempie]

I think that fixed the issue for me. I'll continue to test and try to reproduce it but looks good!

[kristijanhusak]

@sempie @gerazov I pushed a fix to tree-sitter branch that refreshes the tree every time something needs to be done. This should fix all of your issues. No need to enable highlights if you don't want, it should work either way. Let me know if everything is ok.

[gerazov]

Works on my side as well :clap:

Thanks! :pray: