"attempt to index a nil value" when modifying a file opened through the agenda view.

[HendrikPetertje]

Are you using "tree-sitter" branch?

Yes

Describe the bug

When opening an org-buffer from the calendar view, org-specific commands raise lua errors (file nil) while running the same command in a new buffer loading that file without the calendar raises no issues at all.

Steps to reproduce

• open nvim and have some org-mode files setup (with dates so they are picked up by the calendar view
• <leader>oa follwed by a for agenda.
• <ENTER> or <TAB> into an agenda item
• Try to modify date using cid, or forward state of todo using cit or perform any other actions that would require lua to parse the todo under the cursor
• Receive orgmode/parsers/files.lua:208: attempt to index a nil value

Close NVIM (or close the .org buffer) and reopen vim and open the same .org file again (directly without the agenda) all commands now work.

In both cases the ? command still works, it seems to only affect situations where the lua plugin needs to scan/read the file.

Expected behavior

I would expect to be able to make changes to my org files when I open them from the calendar view.

Emacs functionality

No response

Screenshots and recordings

Demo

(I open an event using ENTER and then perform cid on the date object followed by cit on the TODO object) I close nvim

I re-open nvim, go straight to the file and execute the same tasks.

OS / Distro

Mac OSX - Big Sur 11.6

Neovim version/commit

NVIM v0.6.0-dev+496-gc5525f265

Additional context

Build type: Release LuaJIT 2.1.0-beta3

[kristijanhusak]

I'm not able to reproduce this. It's really strange, this should work fine. Can you add set debug=msg or if you use lua vim.cmd[[set debug=msg]] to your init configuration and try to reproduce the issue? Does it report any errors to the command line?

Also, when you select a file from agenda view, try first doing force edit with :e! and then try to do the changes. Does it work?

It would be great to try to reproduce it with minimal init lua https://gist.github.com/kristijanhusak/a0cb5f4eb2bad3e732a1d18d311ebe2f

[levouh]

This happens to me relatively infrequently as well, just haven't been able to pin down exactly what causes it. Opening the same file and performing the exact same operations again often gets rid of the issue (obviously it'd be best to fix it, but its hard to reproduce).

[kristijanhusak]

@HendrikPetertje @levouh when this happens, can you check what this returns: :echo nvim_buf_get_name(0) ? And once you restart and it works, do the same thing again, and let me know if there are any differences between the outputs. I'm grabbing current file name with nvim_buf_get_name(0), and maybe something messes up there and returns things differently. I noticed on demo that statusline shows full path of the file when opened from agenda view, and only file name when opened directly. Vim can get confused sometimes with CWD and such things, so I maybe need to find a way to tackle it.

[levouh]

Will do.

[levouh]

Also just had this happen when doing <s in a normal .org file (not the agenda view). The stack trace is:

E5108: Error executing lua ...k/packer/start/orgmode.nvim/lua/orgmode/org/mappings.lua:335: attempt to index local 'item' (a nil value)

and

:lua print(vim.api.nvim_buf_get_name(0))

returns:

/home/amasquelier/org/test.org

[kristijanhusak]

@levouh does it happen every time you do it? If yes, please give me the content you are trying to promote with that.

[kristijanhusak]

Ok, I think I know what's the issue. Syntax is probably not ok for certain things and treesitter reports an error and fails to parse the document. In @HendrikPetertje first like has #+TITLE Default TODOS, but #+TITLE is missing a : after. If you are using TS highlights (which are still experimental unfortunately), you should get proper highlighting.

For example, here is how it looks for me when it's errored:

And this is when it's ok:

@levouh I assume you had similar issues where something was not being able to be parsed and you got an error.

Somehow it's able to recover (to some extent), once the file is reopened. I'll figure out how to solve or at least communicate this to the user.

[kristijanhusak]

I added some diagnostics error reporting which should make these things more clear. If you are using v0.6.0 (currently master branch) of Neovim, you will get errors via vim.diagnostic api. If not, you will need to run :OrgDiagnostics command to view the errors. I explained same thing here https://github.com/kristijanhusak/orgmode.nvim/blob/tree-sitter/DOCS.md#diagnostics. Let me know how this works for both of you.

[levouh]

@levouh does it happen every time you do it? If yes, please give me the content you are trying to promote with that.

Its inconsistent, I'll enable diagnostics and let you know if there is any obvious relationship between the document parsing errors and this issue.

[HendrikPetertje]

So sorry, been super busy with other issues for a few days, I'll try your stuff tomorrow!

[HendrikPetertje]

I just fixed the titles on my items, nice catch!.

When I open an item from the calendar and then try to manipulate dates or forward the state (or any other action that would affect the file) I still get thrown in to an error situation

:e! doesn't fix that sadly, closing the buffer entirely and then re-opening it with :e filename does work!

The vim config I'm doing this with is: https://git.hendrikpeter.net/hendrikpeter/pico-vim

I tried your Gist with minimal lua, but opening org files using that config results in this:

I'll poke around a bit, turn settings off and on and see what happens!

[HendrikPetertje]

side-detail: there is another case where the nil error can happen from time to time that is irrelevant to this specific bug (I think, but probably the problem @levouh is running into):

1. Open a file with org stuff, dates and todos
2. Insert a new line somewhere
3. attempt to change date, state or other information on a todo item (below the new newline)
4. Same nil failure as OP.
5. save file
6. attempt to change date, state or other info again: great success!

I don't really see that as a bug though; i can just save the file after adding new stuff.

[HendrikPetertje]

While restoring nvim back to my own config I performed a PlugUpdate followed by :TSUpdate to get everything back to what it should be and upgrade stuff while I'm at it

and the problem in OP is gone now and so is the use-case I wrote 5 minutes ago

Feel free to close this, rebuilding LUA fixed it I think

[kristijanhusak]

@HendrikPetertje awesome, thanks. I'll leave it open for now in case someone finds any similar issues or if @levouh manages to reproduce it.

[kristijanhusak]

Closing this since it's been a while since someone reported anything, and now with 0.6.0 out we have proper diagnostics api. There are still some parsing issues that I hope will be resolved once tree-sitter grammar gets 1.0.0 release. If something strange pops up let me know.