I can't understand why when I open (Win10) gvim91 and press :<up> I don't see my most recent command. I'm sure it used to be this way in previous versions of vim (I updated recently).

What I see are kind of recent, but there are obvious gaps where I know there should be commands I've done in the past session.

Also, when I press q: and view command history this way, I see a different view of my commands. Again, obviously recent but with gaps.

In both I don't see commands I would expect and know I have made.

And then, when I view my viminfo file, after the header "# Command Line History (newest to oldest):", the list is different again from both q: command history and :<up>.

I believe that viminfo is only written when a buffer or window is closed and I've taken this into account.

Can someone explain what's going on?


OK I realise I'll need some proof of this. I've recorded the following actions with vim closed.

  1. Open viminfo. You can see the list of the latest commands (which are not in fact latest commands but that's the problem!)
  2. Open a test file and source a session file to get it sitting pretty under the viminfo file for recording purposes. (My problem doesn't usually involve session files).
  3. Hit :<up>. As you can see, if you're quick, is that as I hit <up> the supposed most recent commands do not match those in the viminfo files.
  4. I now enter command history with q:. Again, as you can see, the list doesn't match that in viminfo file. Nor, if you care to watch the gif from the beginning, does it match the list when entering :<up>.
  5. I close the test file. The opened viminfo wants to load the newly written viminfo file; which it does. But look! The 'latest' commands do not list the commands from the test file. In fact, the first one is a command from a session ages ago.

enter image description here

PS: A pity can't post vid files here: GIFs are difficult to 'parse'.


enter image description here


More forensics :) For this I renamed (ie removed) the viminfo to start a new one.

  1. Open blank vim.
  2. Run :grep 'drawtext' *ffmpeg*, :cope, :cclo and :q!.
  3. Open blank vim.
  4. Run :e ffmpeg …, :g/drawtext, q:, :q and :q!.

The output of the last q: was:

grep 'drawtext' *ffmpeg*
e ffmpeg-video-text-overlay.md
  1. I open another blank vim and run :history then :q.

The output from this :history command was:

      #  cmd history
      1  cclo
      2  cope
      3  grep 'drawtext' *ffmpeg*
      4  e ffmpeg-video-text-overlay.md
      5  g/drawtext
      6  q
      7  q!
>     8  history
  1. I open viminfo file. The contents of # Command Line History section (in its entirety):
# Command Line History (newest to oldest):
:e ffmpeg-video-text-overlay.md
|2,0,1709726741,,"e ffmpeg-video-text-overlay.md"
:grep 'drawtext' *ffmpeg*
|2,0,1709726741,,"grep 'drawtext' *ffmpeg*"
  • The content of .viminfo being different from q: or :<Up> is expected, but without seeing either list it will be hard to reason about the discrepancies you describe. Can we have a minimal reproducible example? How many sessions do you have open at the same time?
    – romainl
    Mar 5 at 14:34
  • viminfo file is only written once exiting Vim or explicitly using the :wviminfo command Mar 5 at 15:18
  • Do you have a discrepency between the list that appear when you hit q: and the order of the command that comes with :<up>? Mar 5 at 15:33
  • I am aware that viminfo only written when exiting vim. Testing was done with this fact in mind. And, yes, there's a discrepancy in the listing between q: and order of commands when hitting :<up>. Also a discrepancy between listing of either of the above when first opening vim and the contents of viminfo # Commands
    – Tom
    Mar 5 at 23:56
  • Thanks for the feedback. One more question: Do you have multiple sessions of Vim running in parallel (more than one vim process at the same time)? Mar 6 at 4:35

1 Answer 1


The sequence of the commands that you see in the list triggered by:

  • q:
  • :hist

should be the list of commands you executed (the last executed one in the bottom of the list).

The :up should retrieve the last one.

The :upup should retrieve the penultimate.

The :upupup should retrieve the third-to-last.

Remark: :hup do the same but filters the commands that starts with h. To get rid of the filtering effect you can use :Ctrl p

Under the Hood

The viminfo file contains the list of commands that have been validated (Enter) or canceled (Esc) together with the timestamp corresponding to their last validation or cancellation.

Vim writes the viminfo when you quit the Vim session (or when calling :wviminfo). When it writes the viminfo it actually merges the viminfo with the current content of the viminfo on disk.

It updates the timestamp of each command used or insert new command in the history with their timestamp.

The viminfo list of commands starts with the commands updated by the last session of Vim that exit or that called :wviminfo.

Remarks: This implies that the commands in the viminfo file are not sorted by timestamp when there were multiple sessions of Vim running in parallel.

Viminfo order vs. History order

The commands in Vim are listed according to the timestamp of their execution and not in the order they appear in the viminfo file. This explains why the order is different.

Viminfo content vs. History content

Although :wviminfo merge the content of the viminfo on disk it doesn't update the content of the history. This explains why some commands could be missing in the history when you have concurrent sessions of Vim.

:rviminfo doesn't update the timestamp

Although :rviminfo reads the the content of the viminfo and update the history it seems that it doesn't update the command timestamp. The new command will be positioned correctly but command of concurrent session will not be re-positioned after :rviminfo.

  • 1
    In english we say "penultimate" or "second-to-last", then "third-to-last" :)
    – D. Ben Knoble
    Mar 5 at 16:52
  • Thanks I have used Google translate to get a suggestion but the nothing compare to a human :-) Mar 5 at 17:26
  • 1
    Thanks for your help. I traced problem to Markbar plugin.
    – Tom
    Mar 7 at 11:35

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.