I have a variety of vimscripts for different filetypes in ~/.vim/after/ftplugin, e.g. text.vim, vim.vim, etc. These contain a variety of settings, mappings, etc. Only recently, I've noticed (not sure why it took me so long!) that these scripts get re-run, and the settings re-applied, every time I save the file. This is annoying, for example, if the vimscript runs set textwidth=78, I then manually change the textwidth and then save the file. Normally I want that setting to persist, at least for this editing session, but it's immediately changed back.

Is this expected behaviour? I think what might be happening here is that the files are re-run because the filetype detection logic is re-evaluated when I save the file.

Is there a standard pattern/approach to work around this behaviour? I looked at the help for runtimepath but it didn't help much.

  • 3
    Is it possible that you have an autocmd that is triggering this behavior? I'd expect this to happen if you re-read your file with :e, but not really when you write it... Can you try a simpler reproducer under vim --clean or similar?
    – filbranden
    Commented Jun 14, 2020 at 22:58
  • 1
    +1 It should not happen by default on saving the file. As filbranden said, there likely is an autocommand that interferes. If you don't find it, you could always add an anti-reinclusion guard in your fplugin as a workaround. BTW, what does :verbose set tw? says? Is it really your ftplugin the culprit? Commented Jun 14, 2020 at 23:17
  • 2
    To expand on this: ftplugin is (re-)read upon FileType event, and FileType is normally set on BufReadPost (aka. BufRead). So it looks like a local problem.
    – Matt
    Commented Jun 15, 2020 at 6:31
  • Hmm, OK, thanks a lot, this helps. It wasn't clear whether this was expected or not. I've narrowed it down and for now this seems to be only happening on Markdown files. Some more digging to do... Commented Jun 15, 2020 at 10:55

1 Answer 1


In the end, the comments above were very helpful in narrowing down the problem - thanks, everyone! I've resolved it now, and the filetype is only set once. To summarize, there were several issues here:

  • The problem only affected Markdown files, which I didn't originally realise - sorry for not being more thorough in my original problem determination. This was primarily because I had an autocmd BufRead,BufNewFile *.md set filetype=markdown in my ~/.vim/filetype.vim - this was an old workaround from this issue where it used to be that *.md was incorrectly detected as Modula-2, which does not apply on modern versions of Vim, but I never removed the workaround. This meant there were two autocmds which set the same filetype.

  • I was incorrectly specifying my autocmds as autocmd BufRead,BufNewFile,BufWritePost ... which was causing duplicate calls to set filetype each time a file was saved. The BufWritePost is redundant and can be removed. Reading :help ftdetect helped a lot.

  • 1
    I'm not saying I'd necessarily recommend it, but I can see the logic behind including BufWritePost in your autocommand. It would set the filetype in the scenario that you start editing a file without a name (e.g. via :new) and then subsequently write it out with the specified file extension. If you use :setfiletype instead of setting the 'filetype' option directly, then you'd avoid the repeated script-run issue.
    – Rich
    Commented Jun 16, 2020 at 9:34
  • @Rich agreed on your first point, and it's irritating. On the second, that makes sense, although inexplicably it seems the supplied file detection rules don't use it, making them tricky to override: github.com/vim/vim/blob/master/runtime/filetype.vim#L975. Commented Jun 17, 2020 at 10:33
  • 1
    Not sure if you've misread the line you link to: it uses setf which is an abbreviation of setfiletype.
    – Rich
    Commented Jun 17, 2020 at 10:36
  • @Rich d'oh! You're quite right, I'm sorry. In my mind I was translating that to set filetype= but of course it's not. Thanks! Commented Jun 17, 2020 at 14:10
  • 1
    Easy to do. They're very similar syntaxes!
    – Rich
    Commented Jun 17, 2020 at 14:13

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.