When doing this:

vim -S Session.vim OTHER_FILE

The shown buffer contains the last opened file in the Session.vim and not the file OTHER_FILE. I find this behavior a bit disturbing, I would have found it more coherent to show the content of the file OTHER_FILE. (OTHER_FILE does not appear in the Session.vim file)

After reading the Vim documentation, it appears that session files are loaded after having opened other files provided by arguments. So if the session contains an edit statement, this is logical that the shown buffer contains the file of that edit statement.

With the help of the following function, it now shows the last file provided by argument:

function! GoToLastArgumentFile()                                                                  
    let l:current_buf_id = bufnr('%')                                           
    let l:highest_buf_id = l:current_buf_id                                     
    for buf_id in range(1, bufnr('$'))                                          
        if bufexists(buf_id) && l:current_buf_id != buf_id && bufloaded(buf_id) 
            let l:highest_buf_id = buf_id                                       
    if l:highest_buf_id < l:current_buf_id                                      
        execute ":buffer ".l:highest_buf_id                                     

And also by adding this line in the .vimrc file:

autocmd! VimEnter * :call GoToLastArgumentFile()

I am pretty new at vim script, I found that solution a bit complicated and I was wondering if there was any better way to change the default behavior ?

  • A proponent of the KISS philosophy might consider just starting with vim OTHER_FILE and when ready to work on the session-based stuff do :source Session.vim.
    – B Layer
    Jan 2, 2021 at 16:20
  • Just FYI, there is a SessionLoadPost autocmd event. If it works as one would expect that's probably a more appropriate trigger than the general VimEnter.
    – B Layer
    Jan 2, 2021 at 16:31
  • @BLayer, in fact I was in the KISS philosophy for the last few years. I only started to have needs for kindof IDE features a few weeks ago. Only a reduced description of my issue is posted here, it is part of a more complicated configuration. Thanks a lot for suggesting the event SessionLoadPost. It is a way better idea than VimEnter in this case. I am going to to do a few tests then I will update my question.
    – djoproject
    Jan 2, 2021 at 17:23
  • 1
    Welcome to Vi and Vim! Indeed, you might want to explain the motivation for restoring a session and opening a file in the same command-line. Using a session is usually good for when you're saving and restoring your workspace. So why not restore it and then open the other file? If you're using a session for something different, that might explain it... In which case, you might want to explain what you're trying to accomplish, so you can get better advice.
    – filbranden
    Jan 2, 2021 at 19:01

1 Answer 1


You can cheat a little using this method:

vim -S Session.vim -c ":e OTHER_FILE"

This will source your Session.vim then load the file you want. From what I have read in the man page, the commands specified with -c will be executed last:

-c {command}
    {command} will be executed after the first file has been read. {command} is interpreted
    as an Ex command. If the {command} contains spaces it must be enclosed in double quotes 
    (this depends on the shell that is used). Example: Vim "+set si" main.c
    Note: You can use up to 10 "+" or "-c" commands. 

It won't change the initial behaviour of vim but it will always work.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.