auto save/load not working

[shelper]

i installed this plugin without any modification
commands all run well
but just no autosave/load even i enabled the opts.
echo checked in vim, they are set to 1
but still no luck...
anything i miss?
what i put in my vimrc is:

let g:session_autosave = 1
let g:session_autoload = 1

also tried;

let g:session_command_aliases = 1
let g:session_directory = "~/.vim_runtime/sessions"
let g:session_autoload = 'yes'
let g:session_autosave = 'yes'

no luck..
thanks

[k2s]

please try to put exactly this to your ~/.vimrc:

let g:session_autoload="yes"
let g:session_autosave="yes"

[diego898]

I have this same issue after placing the following in my ~/.vimrc

" Vim-Session Settings
let g:session_autosave = 'yes'
let g:session_autoload = 'yes'
let g:session_default_to_last = 1
let g:nerdtree_tabs_open_on_gui_startup = 0

[xolox]

Sorry for the long silence. I realized just now that the problem might be very simple:

• Auto-save only works when you have an active session (e.g. v:this_session is set);
• Auto-load only works when a session script exists for the default or last used session.

To confirm my suspicion: Open Vim and execute :SaveSession default, then quit Vim. Does auto-load/save work after this? I suspect it does. If so, I should do one of the following but I'm not yet sure which:

• Improve the documentation to explain how to get started with the plug-in
• Improve the code so that it automatically offers to save your session when no session files exist yet and you quit Vim

[xolox]

See also issue #25 which prefers the code change (I think I agree).

[xolox]

This should be fixed in version 1.7.2 released just now. Thanks for the bug report! I'm closing this issue now, but if any of you have problems with the new version feel free to reopen this issue.

[diego898]

Hello,

I did indeed manually create my first session as you described, however, it doesn't seem to be working. When I restart vim I see a blank window. I have to manually type :OpenSession after I start vim to get it back. The auto save session does indeed work. I tested it by changing my session and just closing vim, and when I open I have to type OpenSession and the correct changes appear. The only piece that doesn't seem to be working is the auto-load.

I've tried it with 1.7.2 as well and still have the same problem.

[xolox]

Okay it sounds like there's something else going on here. I looked at the settings you posted previously and I don't see why this shouldn't be working as documented (it is for me :-). There could potentially be a lot of reasons, so below are some random stabs in the dark. Please execute the Vim commands below and report their output (in GVim you should be able to copy/paste from the dialog):

:call confirm(string(xolox#session#get_names()))
:call confirm(printf("bufnr: %i", bufnr('$')))
:call confirm(printf("bufname: %s", bufname('%')))
:call confirm(printf("modified: %i", &mod))
:call confirm(printf("lines: %i", len(getline(1, '$'))))

[xolox]

I just thought of one more thing: Can you take a look at your ~/.vim/sessions directory and tell me whether there is a file called last-session.txt there? If the file exists, what is the content of the file?

[diego898]

The commands had the following results (in a popup dialog)

1 - ['default']
2 - bufnr: 7
3 - bufname: todo
4 - modified: 0
5 - lines: 17

The last 4 are specific to the file I'm currently working on correct?

There contents of ~/vimfiles/sessions (windows machine) is:

default.vim
default.vim.lock
last-session.txt

The contents of last-session.txt are:

default

[xolox]

Thanks for the quick reply! Did you execute the Vim commands right after starting Vim, when you would have expected your session to auto-load? I'm sorry I forgot to mention that! It is very important: the vim-session plug-in looks at the state of your Vim when Vim was just started to determine whether it is appropriate to (ask the user whether to) load a session. What I'm trying to figure out is whether: 1. the plug-in thinks it's not appropriate to load a session or 2. there's a bug hiding somewhere else :-).

[diego898]

Ah I see! Well something interesting just happened. I restarted vim and was greeted with the usual blank window. Typing your 2nd command however gave me a non-zero number, so I went ahead and issued a close all buffers command: :1,1000 bd<cr> and restarted vim and my previous session started up beautifully with nerdtree open and everything! However from here, I just type :q and reopen vim only to be on my empty screen again (session not loaded). Closing all buffers and restarting does the trick again though. In other words - load vim, blank screen, close all buffers, restart vim - session opens as expected - restart vim, blank screen - close all buffers ...

When I open vim and it doesn't load the session correctly, executing your commands give me:

1 - ['default']
2 - bufnr: 2
3 - bufname: 
4 - modified: 0
5 - lines: 1

The 3rd one did indeed have nothing after the bufname

Typing :ls gives me

1 %a  "[No Name]"     line 1
2        "todo"              line 17

Where todo refers to the name of the file I was on when the session did load correctly!

[xolox]

Wow, I'm lost. Either another Vim plug-in is doing this or this is a Vim feature I'm not aware of... Can you execute :verbose set viminfo? and report the output here?

[diego898]

It reads:

viminfo=%,'100,<50,s10,h,rA:,rB:
    Last set from ~/.vimrc

[xolox]

If it's not an esoteric Vim feature or another plug-in, there's only other thing I can think of: Does your original session have one or multiple tab pages? If only one, please try opening several tab pages, save the session, restart Vim and see if you get anything useful back.

This may sound like magic, but there's an explanation of course (if you're interested): The plug-in does some funky magic with opening and closing buffers here and there, which has a tendency to sometimes also close the associated tab page and/or split window, causing sessions to become corrupt. There have been bugs like that before, they got squashed, but there might be more left (the compatibility with plug-ins like NERDTree makes vim-session way more complex than I'd like it to be).

[xolox]

Okay maybe it's not a very esoteric Vim feature at all, just a feature I didn't know about: When % is included in the value of viminfo the buffer list is persisted in ~/.viminfo and restored when Vim is started without any arguments. I guess in this case the plug-in should ignore the buffer list? I'll work on a fix.

[diego898]

Hey I tried opening a new tab and things got crazy/didn't work.

I have the following line my ~/.vimrc that is responsible for that:

" Remember info about open buffers on close
set viminfo^=%

In all honesty, I added it to my ~/.vimrc at the suggestion of a friend without fully understanding the implications!

[xolox]

I just published version 1.7.3 in which auto-load should work correctly regardless of the viminfo option. Can you confirm that it works correctly now? Thanks for the remote debugging session :-) you helped me squash a bug!

[diego898]

Everything seems to be ok! I close all buffers, quit vim, deleted all of my sessions, updated and started fresh. Things seem to be working although there is two slightly strange things:

1. The current directory on NERDTree is not saved with the session. It always starts on ~/myname/Desktop, the directory I make gvim start out of by the shortcut I use. Vim's cwd changes quickly however, due to things in my vimrc that makes its current directory match that of the open file.
2. Upon startup, both nerdtree and the file that is shown (correctly coming over from my last session which is good) are both shown at their very very bottom. In other words, a file with lines 1-30, starts with line 30 at the very top of my screen with vim showing me ~ for 70 lines? NERDTree also starts "too high" as it were. A quick gg fixes it, just found it a little strange.

Anyway, if these make immediate sense/quick fixes then go for it! Otherwise, these are really no big deal. Thanks for your effort!

[xolox]

Thanks for the feedback Diego! I've created a new issue (#40) to keep track of your bug reports, because the original problem reported in issue #19 is now resolved.