[vim/vim] Remove 'r' and 'o' from formatoptions. (PR #11700)

16 views
Skip to first unread message

dundargoc

unread,
Dec 13, 2022, 12:25:43 PM12/13/22
to vim/vim, Subscribed

I don't think these particular options should be set from a ftplugin as
I don't believe them to be relevant to the C or Vim languages. I know
it's possible to override this with the "after" directory, but I feel
like this is a more "correct" behavior by not setting these in the first
place.


You can view, comment on, or merge this pull request online at:

  https://github.com/vim/vim/pull/11700

Commit Summary

  • d1e72dd Remove 'r' and 'o' from formatoptions.

File Changes

(2 files)

Patch Links:


Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700@github.com>

codecov[bot]

unread,
Dec 13, 2022, 12:38:38 PM12/13/22
to vim/vim, Subscribed

Codecov Report

Merging #11700 (d1e72dd) into master (692fe08) will decrease coverage by 0.68%.
The diff coverage is n/a.

@@            Coverage Diff             @@

##           master   #11700      +/-   ##

==========================================

- Coverage   81.81%   81.13%   -0.69%     

==========================================

  Files         164      154      -10     

  Lines      191188   181055   -10133     

  Branches    43409    41039    -2370     

==========================================

- Hits       156418   146892    -9526     

+ Misses      22071    21327     -744     

- Partials    12699    12836     +137     
Flag Coverage Δ
huge-clang-none 82.67% <ø> (-0.01%) ⬇️
huge-gcc-none ?
huge-gcc-testgui ?
huge-gcc-unittests 0.29% <ø> (ø)
linux 81.13% <ø> (-1.32%) ⬇️
mingw-x64-HUGE ?
mingw-x86-HUGE ?
windows ?

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files Coverage Δ
src/if_perl.xs 54.50% <0.00%> (-17.82%) ⬇️
src/regexp_nfa.c 80.56% <0.00%> (-9.20%) ⬇️
src/arabic.c 85.86% <0.00%> (-8.70%) ⬇️
src/typval.c 82.95% <0.00%> (-8.33%) ⬇️
src/regexp_bt.c 78.50% <0.00%> (-7.47%) ⬇️
src/vim9execute.c 82.97% <0.00%> (-7.18%) ⬇️
src/json.c 77.84% <0.00%> (-5.47%) ⬇️
src/vim9compile.c 86.82% <0.00%> (-4.69%) ⬇️
src/vim9instr.c 77.22% <0.00%> (-4.63%) ⬇️
src/cmdexpand.c 86.55% <0.00%> (-4.34%) ⬇️
... and 137 more

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.


Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/c1349227591@github.com>

Bram Moolenaar

unread,
Dec 13, 2022, 2:02:07 PM12/13/22
to vim/vim, Subscribed

The options have the correct value. For these languages a comment continues only
when the comment leader is inserted in the next line. Without that you cannot edit
multi-line comments without much effort.
For C a "/" kind of comment could theoretically do without a comment leader, but nearly
all files put a "
" in the next line to indicated the comment continues.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/c1349529636@github.com>

Bram Moolenaar

unread,
Dec 13, 2022, 2:02:11 PM12/13/22
to vim/vim, Subscribed

Closed #11700.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/issue_event/8029328782@github.com>

madjxatw

unread,
Dec 20, 2022, 9:33:25 AM12/20/22
to vim/vim, Subscribed

This behavior is really annoying! Whether to insert a comment leader should be decided by user but not assumed by the editor. Most of the time when placing a short trailing comment, I don't want a comment continuation. At least o should be removed.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/c1359454824@github.com>

Christian Brabandt

unread,
Dec 20, 2022, 10:56:10 AM12/20/22
to vim/vim, Subscribed

you can use either use Optionset autocommand or use after/ directory to override values that you do not like personally.


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/c1359603830@github.com>

Gary Johnson

unread,
Dec 20, 2022, 1:14:01 PM12/20/22
to reply+ACY5DGDDMPOVFY3VOF...@reply.github.com, vim...@googlegroups.com
On 2022-12-20, madjxatw wrote:
> This behavior is really annoying! Whether to insert a comment leader should be
> decided by user but not assumed by the editor. Most of the time when placing a
> short trailing comment, I don't want a comment continuation. At least o should
> be removed.

From my vimrc:

autocmd FileType * setlocal formatoptions-=o
" Override any filetype plugin's attempt
" to set the 'fo' 'o' option, which inserts
" a comment leader when opening a new line.

HTH,
Gary

vim-dev ML

unread,
Dec 20, 2022, 1:14:20 PM12/20/22
to vim/vim, vim-dev ML, Your activity


Reply to this email directly, view it on GitHub.

You are receiving this because you are subscribed to this thread.Message ID: <vim/vim/pull/11700/c1359946219@github.com>

madjxatw

unread,
Dec 21, 2022, 2:37:31 AM12/21/22
to vim/vim, vim-dev ML, Comment

you can either use Optionset autocommand or use after/ directory to override values that you do not like personally.

OptionSet formatoptions doesn't work for me while FileType works. I used to place a after/ftplugin/<filetype>.vim to tweak formatoptions for each filetype I was using, but I finally gave up when I found that I had to place a considerable number of them, and I often have to work on different machines where vim is not configured same way. From my point of view, the auto insertion should only apply when the comment being typed in Insert mode exceeds the text width of current line. Some people perhaps need it on some specific filetypes, but why not leave it to users to decide.


Reply to this email directly, view it on GitHub.

You are receiving this because you commented.Message ID: <vim/vim/pull/11700/c1360957010@github.com>

Reply all
Reply to author
Forward
0 new messages