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.
https://github.com/vim/vim/pull/11700
(2 files)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
Merging #11700 (d1e72dd) into master (692fe08) will decrease coverage by
0.68%.
The diff coverage isn/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.![]()
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.![]()
Closed #11700.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
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.![]()
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.![]()
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.![]()
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.![]()