I'd like vim to automatically open files at line 1 instead of where it left off the last time. I tried putting gg in .vimrc, but that didn't work. There's must be some way to do this.

  • 1
    This isn't a default vim configuration as far as I'm aware. Do you already have something special in .vimrc, /etc/vim/vimrc, or similar? What happens if you start with vim -u NONE?
    – Chris Down
    Dec 28, 2019 at 21:57
  • @Chris Perfect, just what I was looking for. As for the default behavior, opening where you left off is something I've had to live with for years. I always hated it. Dec 28, 2019 at 22:57
  • 1
    On my system, vim never starts where it left off, but I have no idea why. You can also use vim +1 filename to start at line 1. Dec 28, 2019 at 23:03
  • 1
    Hi @ChrisDown, great to see you here! This issue is caused by an (unfortunate) rule shipped by RHEL/CentOS/Fedora in the system-wide /etc/vimrc. Recently I helped someone with the opposite problem, moving to a custom build of Vim, they missed the CentOS behavior and wanted it back...
    – filbranden
    Dec 29, 2019 at 4:28
  • 1
    @filbranden Hah, fancy seeing you here. I'll give an "oh dear" to that as a distro default :-)
    – Chris Down
    Dec 29, 2019 at 12:41

2 Answers 2


CentOS, RHEL and Fedora ship a system-wide vimrc file at /etc/vimrc that sets up an autocmd that will jump to the last mark of a file whenever one is found.

The installed autocmd looks like this:

augroup redhat
" When editing a file, always jump to the last cursor position
autocmd BufReadPost *
\ if line("'\"") > 0 && line ("'\"") <= line("$") |
\   exe "normal! g'\"" |
\ endif

(The main difference being that the name of the augroup is "fedora" on Fedora and "redhat" on RHEL or CentOS.)

While it is possible to disarm this rule by changing the 'viminfo' setting to prevent Vim from saving marks on the viminfo file, that has the unfortunate side effect of having it stop preserving that information altogether, which is otherwise useful in certain situations.

A more direct and precise approach to disable this behavior is to delete the rule, which you can do from your user's vimrc file, since it's sourced after the system-wide config.

You can use the following command to delete that rule on CentOS:

autocmd! redhat BufReadPost *

And this one to delete it on Fedora:

autocmd! fedora BufReadPost *

You can safely add both rules in your vimrc file, since they don't do anything unless those rules exist (presumably from the system-wide vimrc file.)

These commands will remove that single rule from the augroup, rather than clear the augroup altogether, since the augroup also installs other unrelated autocmds that might be desirable, therefore the suggestion to delete that one particular rule only.


I suspect this is related to the viminfo setting. From help viminfo:

  1. The viminfo file

If you exit Vim and later start it again, you would normally lose a lot of information. The viminfo file can be used to remember that information, which enables you to continue where you left off.

The viminfo file is used to store:
- The command line history.
- The search string history.
- The input-line history.
- Contents of non-empty registers.
- Marks for several files.
- File marks, pointing to locations in files.
- Last search/substitute pattern (for 'n' and '&').
- The buffer list.
- Global variables.

A possible value for the viminfo entry is:

" Tell vim to remember certain things when we exit
"   '20  :  marks will be remembered for up to 20 previously edited files
"   "100 :  will save up to 100 lines for each register
"   :20  :  up to 20 lines of command-line history will be remembered
"   %    :  saves and restores the buffer list
"   n... :  where to save the viminfo files
set viminfo='20,\"100,:20,%,n~/.viminfo

You can see what you're viminfo is set to with:

:set viminfo?

You could update that to change '# to '0. From the example above:

set viminfo='0,\"100,:20,%,n~/.viminfo

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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