error when writing file with no filetype

[justinmk]

If I write/save a file that was restored from a session (which does not set up filetype autocmds, and &ft is empty), :writing the file causes:

Error detected while processing BufWritePost Auto commands for "*": E121: Undefined variable: b:sy_path E116: Invalid arguments for function sy#start

Editing the file with :e to load the syntax/filetype plugins fixes the issue, even after setting :set ft= again (I guess because autocmds are already set up).

I realize this is probably an edge case (I assume most people gave up on vim sessions), so I will try to debug it myself if it annoys me enough. Just putting it here to see if anyone else ran into it. I think it started happening since the last 5 or so commits.

[mhinz]

Yes, it's quite reasonable that it started happened around 5 commits ago (when we switched from one fat global variable to buffer-local variables.)

I can't really reproduce it, though. I just created a plain file with one sentence in it and saved it in a session (and of course people are still using sessions.. vim-startify! :D). I sourced that session under different circumstances: 1) non-VCS file 2) VCS file with no changes and 3) VCS file with changes, but it all seemed to work.

If b:sy_path isn't set, it means that the BufRead/BufEnter events weren't triggered. Let me dig into it..

EDIT:

I still can't reproduce it and I never used SessionLoadPost so far, but maybe this is enough already: change line 17 in plugin/signify.vim from:

  autocmd BufRead,BufEnter * let b:sy_path = resolve(expand('<afile>:p'))

..to..

  autocmd BufRead,BufEnter,SessionLoadPost * let b:sy_path = resolve(expand('<afile>:p'))

Does this quick shot work?

[mhinz]

@justinmk ping

[justinmk]

Sorry about the delay on this. Just tried adding SessionLoadPost, and things seem good now!

If b:sy_path isn't set, it means that the BufRead/BufEnter events weren't triggered

Right, I have Vim configured to I restore my session on VimEnter by sourcing the session file. For some reason, that doesn't fire FileType or BufEnter or whatever, so when I first start up Vim, I have to do an initial :edit on each file. Yes this completely sucks, but I never was able to figure out how to fix it. I tried something like :bufdo e but that caused errors due to some variables in the session not being initialized until after the bufdo executed at VimEnter. But actually, I might just live with the errors since doing :edit manually is worse.

Since you obviously have a lot of experience with Vim sessions, I would love to hear any insight about this. My understanding of vim-startify is that the user must first choose a session to restore, which would avoid problems with VimEnter.

[mhinz]

Hmm, maybe you need to use a nested autocmd:

autocmd VimEnter * nested if filereadable('Session.vim') | source Session.vim | endif

See: https://groups.google.com/forum/#!topic/vim_use/9gjdAAIvvaw

All filetype-related files are loaded using an autocommand, but by default no autocommands are allowed when you are executing an autocommand, so you should add `nested' just after the pattern.

Some house-advertising: The big advantage of startify is to have all important files/sessions aggegated into one buffer. So I can quickly choose between my different projects and also enable persistent sessions (so sessions loaded by Startify automatically get saved when quitting Vim).

[justinmk]

add `nested' just after the pattern

Thanks! I just checked my file history and I was using that at one point, but I just added it again, and no errors so far.

I will probably use startify at some point, I'm beginning to have needed for multiple sessions.

[mhinz]

Yay. :-)

[hkjels]

This is still an issue I think. If I create a new file with netrw, the error still occurs. I have to fire :e after the first save to avoid the error-output.

[PhilRunninger]

I just stumbled on this issue while debugging my own vim-sessions plugin. It was not setting the filetypes correctly after sourcing the session file. Your suggestion to use nested fixed it. Thanks!