Closed justinmk closed 10 years ago
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?
@justinmk ping
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
.
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).
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.
Yay. :-)
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.
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!
If I write/save a file that was restored from a session (which does not set up filetype autocmds, and
&ft
is empty),:w
riting the file causes: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.