update v:oldfiles at runtime

[randomizedthinking]

• nvim --version: v0.3.3
• Vim (version: ) behaves differently? same
• Operating system/version: Debian
• Terminal name/version: rxvt-unicode
• $TERM: screen-256color

Steps to reproduce using nvim -u NORC

nvim -u NORC
:oldfiles
:e another-new-file
:oldfiles                      # the oldfile list is unchanged

Actual behaviour

The v:oldfiles is read from shada at startup, and is not updated during the session, so a user cannot access recently closed files in the same nvim-instance. If one quits then re-enters, these files will appear in the v:oldfiles variable.

Expected behaviour

The v:oldfiles should be updated on the fly once new files are opened.

[justinmk]

Technically this would be a breaking change.

Updating v:oldfiles on-the-fly makes it time-sensitive. The more files you open-and-close, the more likely it is that v:oldfiles is a useless list of files already listed in :ls! (bang variant).

---

N.B. To update shada/vimfino on the fly, you can do this:

:rshada | wshada

• :rshada reads and merges the disk contents of the shada file into the current session
• :wshada writes out the merged result

[mhinz]

I just want to mention that v:oldfiles is writable as well. vim-startify uses this by default:

function! s:update_oldfiles(file)
  if g:startify_locked || !exists('v:oldfiles')
    return
  endif
  let idx = index(v:oldfiles, a:file)
  if idx != -1
    call remove(v:oldfiles, idx)
  endif
  call insert(v:oldfiles, a:file, 0)
endfunction

autocmd startify BufNewFile,BufRead,BufFilePre *
          \ call s:update_oldfiles(expand('<afile>:p'))

[justinmk]

@mhinz that might be a good thing for us to put in a standard nvim.vim plugin. Except do it on BufDelete,BufWipeout instead of BufNewFile,BufRead,BufFilePre.

[randomizedthinking]

@mhinz since many plugins will open utility buffers for certain tasks, I wonder whether the code you have will filter them out?

[mhinz]

@randomizedthinking

Yes, the plugin does the filtering when it's run, not when that autocmd gets triggered. But buffers that are not backed by files won't trigger these events in the first place. I just wanted to show that's it's another approach.

It's probably not terribly hard to make this change in Nvim, but the real question is if we really want to break with Vim's behaviour here.

[randomizedthinking]

Personally, I feel it is okay to deviate from vim behavior for such cases. The vim implementation is sub-optimal on this, and inherited by neovim. Most importantly and practically, the change would not break anyone's workflow.

[xiongmao86]

Since oldfiles is taken care of by shada, update v:oldfiles with an autocmd will be enough, am I right?

[randomizedthinking]

@xiongmao86 Yes, I am using minhz's approach with some minor changes, and it works out nicely.

[xiongmao86]

@randomizedthinking , thank you very much for your answer. And there’s one question at last, where should I put the function that update v:oldfiles, should I create a ‘nvim.vim’ file, and place it in the ‘runtime/autoload’ directory?

[randomizedthinking]

@xiongmao86 Having it in your init.vim file would be fine.

[randomizedthinking]

Closing it now since it is rather a minor item, and there is a solution without touching the system. Thanks @justinmk and @mhinz for the help.

[litoj]

@mhinz is there also a way to save that modified history? From what I've tested it only stays in memory in turn not freeing up space in shada for actually wanted files.

Edit: I tried this

local of = {}
for i, v in ipairs(vim.v.oldfiles) do
  if not string.find(v, '.git/', 7, true) and
    not string.find(v, 'NvimTree_', 2, true) then
    of[#of+1] = v
  end
end
vim.v.oldfiles = of
-- vim.cmd.wshada()