Why change formatoptions in ftplugin files?

[Danielkonge]

Some filetype plugin files change formatoptions, and I can see, based on #4680, that this is done on purpose and has been discussed before. My question is what is the advantage of setting formatoptions on a filetype level? I can see how it might be helpful to remove known problematic options for some languages, but I don't see how it helps to add multiple options?

I understand that this will likely not change, and this is not really a request for any changes (though I would support not changing formatoptions in ftplugins), but I would like to know what the advantage is here? Am I missing something, and do some languages have clear advantages with certain formatoptions settings?

[tonymec]

Some 'formatoptions' settings are more useful for some filetypes than for others. In that case, the corresponding filetype-plugin includes a :setlocal command for that particular setting, let's say :setlocal fo+=2 in an additional (e.g. a French user's) ftplugin for text files only (*.txt or similar) to support French-style indenting where the first line of every paragraph is slightly more indented than the rest. Such a setting would make no sense for most other filetypes so its logical place is as a buffer-local setting set by the appropriate ftplugin.

[chrisbra]

Well, I guess there might be users that like it or got accustumed to how it has been handled until now and then there might be users, that really want to control every tiny option value that would be dissappointed if Vim uses some "magic" to change their carefully set format option value.

E.g. I was confused about why one of my options usually didn't work at one point.

:verbose :set <option>?

ususally helps

[dkearns]

fo+=croql fo-=t was/is supposed to be the default for source code and config files. It's not coincidental that all of Bram's ftplugins, with obvious exceptions, make this change. I can also assure you that Nikolai, who appears to be responsible for most of the ftplugins setting this option, was not a cargo-cultist.

Unfortunately, the runtime files are inconsistently implemented as there are hundreds of maintainers. Bram didn't generally monitor the consistency of these files that closely, he wouldn't have had the time. However, Christian is much more open to cleaning this sort of thing up without the maintainer round trip.

To the specific example, presumably only r and o are controversial. Removing them generally generates as much, if not more, noise than their inclusion.

These problems are really the nature of the beast. There's some other default ftplugin settings I strongly dislike. E.g., matching return, continue, and break statements as Matchit middle patterns.

[dundargoc]

fo+=croql fo-=t was/is supposed to be the default for source code and config files.

Doesn't this break the premise that these are supposed to be filetype-specific settings if they're set for all source code and all config files? This isn't so much "these are settings that fit well with this filetype" but more "these are the options that you should be using/that fit well in general". This isn't a bad thing on its own (defaults matter), but the way it's currently set up feels backwards as a user can't just use set the formatoptions to configure the editor as they want, but have to use autocommand as a workaround which is not obvious for users who don't have the context about the internals of vim.

[Danielkonge]

:verbose :set <option>?

ususally helps

This is what I ended up doing and how I found out about the ftplugins. It did indeed help with debugging.

[Danielkonge]

fo+=croql fo-=t was/is supposed to be the default for source code and config files. It's not coincidental that all of Bram's ftplugins, with obvious exceptions, make this change. I can also assure you that Nikolai, who appears to be responsible for most of the ftplugins setting this option, was not a cargo-cultist.

Unfortunately, the runtime files are inconsistently implemented as there are hundreds of maintainers. Bram didn't generally monitor the consistency of these files that closely, he wouldn't have had the time. However, Christian is much more open to cleaning this sort of thing up without the maintainer round trip.

To the specific example, presumably only r and o are controversial. Removing them generally generates as much, if not more, noise than their inclusion.

If these options are basically supposed to be the default options, wouldn't it make more sense to add them as the actual default and then only edit the option if a ftplugin maintainer thinks there is a good reason to change the default?

These problems are really the nature of the beast. There's some other default ftplugin settings I strongly dislike. E.g., matching return, continue, and break statements as Matchit middle patterns.

Yeah, I didn't really expect any change for this, since I assumed there would be many differing opinions on the best option. (That is part of why I made a discussion question instead of an issue.)

[tonymec]

P.S. If that same French user has a few text files where he wants to disable that French-style indenting, he can do it by means of a modeline (q.v.) in those particular files.

[tonymec]

FWIW, these settings are not all the same for all filetypes. I checked a few files currently loaded in my "Rolodex Vim" instance of gvim, and I found the following:

• text and html : left at the Vim default "tcq"
• help : set to "tcroql" at $VIMRUNTIME/ftplugin/help.vim line 16
• vim : set to "croql" at $VIMRUNTIME/ftplugin/vim.vim line 43
• css : set to "croql" at $VIMRUNTIME/ftplugin/css.vim line 18
• javascript : set to "croql" at $VIMRUNTIME/ftplugin/javascript.vim line 17

Bram was well known for his staunch insistence on backward compatibility, and I can't blame him for that. If these filetype-dependent defaults suddenly changed, no doubt many users who depended on them would raise the hue and cry on these very mailing lists.

My advice is to keep them as-is, and let any user who wants some other setting add a $HOME/.vim/after/ftplugin/<somefiletype>.vim (on Unix) or the same with /vimfiles/ instead of /.vim/ (on Windows), which won't trouble other people's settings, rather than require that everyone's defaults be changed to his own settings.

[dundargoc]

If these filetype-dependent defaults suddenly changed

Aren't these files taken verbatim from its maintainers? Surely if they change a value because they deem it necessary then vim has to follow, otherwise it would diverge. These filetypes already don't have any backwards compatible guarantee as I understand it.

[benknoble]

FWIW, I found this annoying enough back in my first few years of vimming to force formatoptions-=cro, which I eventually turned into formatoptions=tcrqlnj, in an autocommand for all FileTypes. With that in place, I haven't needed to tweak formatoptions in a ftplugin in a long time—it's the inconsistency that bothered me, where some of the values affect how o/O/Enter work differently in each file.

[tonymec]

Well, in most cases I like the defaults the way they are, different for different filetypes, considering the fact that different settings for different filetypes are in general IMHO well-chosen the way they are. If for some particular filetype I wanted some different setting, I would add a |filetype-plugin| of a few lines in an |after-directory| and that would be that. So far I haven't felt such a necessity, in contrast to automatic filetype-dependent indenting, which I disable for all filetypes by means of the statement :filetype indent off immediately after :runtime vimrc_example.vim near the top of my vimrc.

[benknoble]

I think we're saying very similar things:

• I dislike the inconsistent behavior of certain insert- and normal- mode commands affected by 'formatoptions', so I (have to) force it to behave the way I want. (I used to use after/ftplugin/… for this until I realized that I really wanted 100% consistent behavior. It's still how I customize most things.)
• You had some issue the indent scripts, so you force them to behave the way you want (by turning them off).

Where we differ, I suppose, is that I expect indent settings and many other buffer-local options set by ftplugins to vary per-filetype. I dislike the notion that hitting enter, o, O, and a few others is so different (especially in terms of what text is magically inserted—or not) just because of the filetype. You seem to say that it is natural for 'formatoptions' and thus the behavior of such commands to differ so much by filetype. (I agree that, for example, inserted comment leaders should differ; I disagree that whether they are inserted should differ.)