Closed randomizedthinking closed 5 years ago
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 resultI 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'))
@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
.
@mhinz since many plugins will open utility buffers for certain tasks, I wonder whether the code you have will filter them out?
@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.
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.
Since oldfiles is taken care of by shada, update v:oldfiles with an autocmd will be enough, am I right?
@xiongmao86 Yes, I am using minhz's approach with some minor changes, and it works out nicely.
@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?
@xiongmao86 Having it in your init.vim file would be fine.
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.
@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()
nvim --version
: v0.3.3$TERM
: screen-256colorSteps to reproduce using
nvim -u NORC
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 thev:oldfiles
variable.Expected behaviour
The
v:oldfiles
should be updated on the fly once new files are opened.