8

Vim automatically continues a comment when I press Enter in Insert mode, which I find helpful.

However, I do not want the comment continued after pressing 'o' from normal mode to insert a new line below the end of the comment.

I read that I need to remove the option o from my formatoptions, so I put this line right at the end of my vimrc file:

set formatoptions-=o

But it has changed nothing, and when I execute :set formatoptions from iside of vim it shows me my formatoptions are croql.

How do I get rid of the 'o'?

Edit:

I've followed some steps pointed out in the comments by Sato Katsura:

The solution starts with running :verb set fo to see where formatoptions was last modified.

Here's the output to verb set fo:

  formatoptions=croql
        Last set from /usr/share/vim/vim73/ftplugin/vim.vim
  • 3
  • 1
    @DJMcMayhem That doesn't solve my problem. As you can see, I have taken the approaches recommended by the answers for that question, and vim's behaviour has not changed. – theonlygusti Aug 26 '16 at 22:10
  • 1
    Yes, I see that. I was too hasty with my close vote, so I have retracted now. However, now it sounds like a problem with your .vimrc, so we can't help at all until you post it. I'm guessing a plugin changes it, or it isn't being source correctly. – DJMcMayhem Aug 26 '16 at 22:11
  • 1
    Basically, the question is "why doesn't the line set formatoptions-=o in my vimrc work?", that this disables comments when pressing o is coincidental :-) – Martin Tournoij Aug 26 '16 at 22:14
  • @Carpetsmoker yeah pretty much... does it need editing? – theonlygusti Aug 26 '16 at 22:15
7

When vim starts, it runs $VIMRUNTIME/ftdetect.vim to find out what type of file you're editing; then, if you have 'ftplugin' set, it sources $VIMRUNTIME/ftplugin.vim which sources $VIMRUNTIME/ftplugin/&filetype.vim (see :help startup for more detail).

You can alter or override $VIMRUNTIME/ftplugin.vim or $VIMRUNTIME/ftplugin/&filetype.vim. Create a folder and subfolder in your home directory called .vim/after.

If you want to override formatoptions for all filetype plugins, edit $HOME/.vim/after/ftplugin.vim, otherwise edit $HOME/.vim/after/ftplugin/lua.vim (or replace lua with whichever language - in your case it's vim). For a proper explanation of how this works, see :help 'runtimepath' (and :help :runtime).

Put the following content in the file:

set formatoptions-=o

You can see whether it's worked by running :scriptnames. You should get a list like the following:

  1: H:\script\vim\vimrc
  2: H:\script\vim\syntax\syntax.vim
  3: H:\script\vim\syntax\synload.vim
  4: H:\script\vim\syntax\syncolor.vim
  5: H:\script\vim\filetype.vim
  6: ~\vimfiles\ftdetect\log.vim
  7: ~\vimfiles\ftdetect\rdp.vim
  8: ~\vimfiles\ftdetect\scratch.vim
  9: ~\vimfiles\ftdetect\sqlite.vim
 10: ~\vimfiles\ftdetect\todo.vim
 11: H:\script\vim\ftplugin.vim
 12: ~\vimfiles\after\ftplugin.vim
 13: ~\vimfiles\colors\desert.vim
 14: H:\script\vim\defaults.vim
 15: H:\script\vim\plugin\getscriptPlugin.vim
 16: H:\script\vim\plugin\gzip.vim
 17: H:\script\vim\plugin\logiPat.vim
 18: H:\script\vim\plugin\manpager.vim
 19: H:\script\vim\plugin\matchparen.vim
 20: H:\script\vim\plugin\netrwPlugin.vim
 21: H:\script\vim\plugin\rrhelper.vim
 22: H:\script\vim\plugin\spellfile.vim
 23: H:\script\vim\plugin\tarPlugin.vim
 24: H:\script\vim\plugin\tohtml.vim
 25: H:\script\vim\plugin\vimballPlugin.vim
 26: H:\script\vim\plugin\zipPlugin.vim
 27: H:\script\vim\syntax\lua.vim
 28: H:\script\vim\ftplugin\lua.vim

Note lines 11 and 12. Your file paths will look a bit different.

  • This might be helpful for someone. In my situation, I use vim-plug, and some plugins(I don't know which) changed the formatoptions, however my .vim/after is sourced after those plugins... – Vold Notz Mar 30 at 8:43
  • I think the correct command is :scriptnames. – Jari Turkia Jun 5 at 5:39
  • By trial and error, I learned that trying to force formatoptions in ~/.vim/after/ftplugins.vim does not work -- then I encountered this argument which sort-of explains why. – Stabledog Nov 7 at 14:58
2

I found out that I can provide a makeshift solution using an autocommand.

The following line in your .vimrc file should apply the new formatoptions everywhere:

autocmd FileType * set formatoptions-=o

However, this doesn't really get to solving the problem; I still don't understand why a simple set wasn't enough, and as has been pointed out in the comments this solution is not ideal.

  • 1
    This may work, but it's very kludgy and not the solution I would recommend. – DJMcMayhem Aug 26 '16 at 22:14
  • @DJMcMayhem hmm, what possible problems could I run into by using this solution? Please feel free to post an answer providing a better solution, I'd obviously prefer it :) – theonlygusti Aug 26 '16 at 22:15
  • Why not @DJMcMayhem? The problem is almost certainly because one of the filetypes sets formatoptions (e.g. Perl, Ruby, and several others set this). This seems like an acceptable solution? – Martin Tournoij Aug 26 '16 at 22:17
  • @Carpetsmoker I suppose that's fair. I hadn't thought of that. It just seems strange to change a setting in an autocmd, rather than just setting it directly. – DJMcMayhem Aug 26 '16 at 22:18
  • 2
    @SatoKatsura Depends on what you want, I guess. Some people might prefer never adding a comment character when using o regardless of the filetype, in which case this seems appropriate. – Martin Tournoij Aug 27 '16 at 18:12
2

I had a similar experience as OP.

I found that t was being added to my formatoptions despite deliberately attempting to disable it.

After using :verbose set fo to be certain it was coming from .vimrc, I noticed that the behavior seemed to be dependent on where I put the formatoptions in my .vimrc file. I discovered that it was happening because of where I had placed set nocompatible in my file:

set formatoptions=qj
set nocompatible

:set fo?
  formatoptions=tcq

It turns out that this is specifically called out in :help nocompatible:

                   'compatible' 'cp' 'nocompatible' 'nocp'
'compatible' 'cp'   boolean (default on, off when a |vimrc| or |gvimrc|
                    file is found, reset in |defaults.vim|)
            global
            {not in Vi}
    This option has the effect of making Vim either more Vi-compatible, or
    make Vim behave in a more useful way.

    This is a special kind of option, because when it's set or reset,
    other options are also changed as a side effect.
    NOTE: Setting or resetting this option can have a lot of unexpected
    effects: Mappings are interpreted in another way, undo behaves
    differently, etc.  If you set this option in your vimrc file, you
    should probably put it at the very start.

After following this good advice, my formatoptions were preserved as desired. I don't know if OP was running into this exact problem or if it was some other interaction, but I was happy to find out what was causing it. Hopefully this helps someone else figure out what's (initially inexplicably) changing their settings.

I also like theonlygusti's autocmd- there are some options I just never want set no matter the file type. I'm looking at you, t.

2

Since lot of us Vim users are suffering from this, I went and investigated this bit more.

My solution is to create the $HOME/.vim/after/ftplugin.vim as suggested by @abcq2 just to realize, it won't change anything. Given the list given by :scriptnames, that file is source way too early. However, the second suggestion of creating a $HOME/.vim/after/ftplugin/lua.vim for LUA-files does help.

By straceing, I learned that file-type generic after-plugins are sourced before the file-type and file-type specific after-plugins are sourced after the file-type. Not very intuitive, but that's how it works.

There is more information in my blog about this.

  • I am not sure why you think an after/ftplugin would help. Rather the better way is to use filetype specific overrides (using either a FileType autocommand or a specific after/<filetype>.vim file). See also the help at :h ftplugin-overrule – Christian Brabandt Jun 6 at 7:15
  • I'm thinking it would help, because @abcq2 suggested it in his answer above. I think I am using after/<filetype>.vim in my answer. – Jari Turkia Jun 6 at 19:32

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.