[vim/vim] formatoptions+=r continues a comment when the line (Issue #10006)
Jonathan Wakely
Steps to reproduce
- vim foo.cc
- insert the following text then hit Enter: "foo; // bar"
In recent versions of Vim the new line continues the comment:
foo; // bar
//
Expected behaviour
The cursor should move to the start of the next line instead of continuing the comment.
I have both r and o in formatoptions, but I only want to continue a comment when the whole line is a comment. When I end a line that contains code followed by a single line // comment, I want another line of code, not to continue the comment. There doesn't seem to be a formatoptions value to select the old behaviour.
Version of Vim
VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Feb 24 2022 00:00:00) Included patches: 1-4460 Modified by bugz...@redhat.com Compiled by bugz...@redhat.com Huge version with GTK3 GUI.
Environment
Fedora Linux 34, konsole, xterm-256-color, bash
(but the same behaviour happens in gvim)
Logs and stack traces
No response
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
I realise that I can just type CTRL-U to remove the comment leader that gets added, but that erases all the way to column 0. If I have indented code:
foo; // barthen I want the cursor to be aligned with foo after hitting Enter. If I use CTRL-U or CTRL-W to erase the comment leader then I need to reposition the cursor at the right column manually.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Christian Brabandt
is this a recent regression? can you bisect this?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
zeertzjq
This feature should be introduced in 6e371ec, and CTRL-U fixes indent when 'cindent' is set starting from 6e371ec.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
Thanks! Is there no way to disable the behaviour introduced by 6e371ec ? I totally understand that some people might prefer it, but shouldn't it be configurable?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
The behaviour being tested here seems great:
If splitting an existing comment into multiple lines, continue it as a comment. That makes perfect sense.
But just hitting Enter after foo; // bar is not the same as reformatting an existing comment, and it's wrong to assume that I want to continue the comment, rather than enter another C++ statement, i.e. a non-comment.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Bram Moolenaar
I know that continuing the comment when hitting Enter, or using "o" to open a new line may not be what you want.
Problem is that sometimes it is. Adding a setting has the opposite effect: if you do want to continue the command you have to align and insert // manually. Whether one or the other happens more often might influence the default behavior.
In my opinion it takes a little while to get used to typing CTRL-U if the comment leader is not desired. It should get the correct indent then, not sure what would interfere with that.
If we would default to not adding a comment and aligning it, then when you do want it there is no simple way to get that, definitely not a single key.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Jonathan Wakely
Fair enough, I'll try to figure out what's interfering with the correct indentation after CTRL-U (something in https://github.com/mattkretz/vim-gnuindent I think).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Yegappan Lakshmanan
I realise that I can just type
CTRL-Uto remove the comment leader that gets added, but that erases all the way to column 0. If I have indented code:foo; // barthen I want the cursor to be aligned with
fooafter hitting Enter. If I useCTRL-UorCTRL-Wto erase the comment leader then I need to reposition the cursor at the right column manually.
vim-dev ML
On Thu, Mar 24, 2022 at 5:59 AM Jonathan Wakely ***@***.***>
wrote:
> I realise that I can just type CTRL-U to remove the comment leader that
> gets added, but that erases all the way to column 0. If I have indented
> code:
>
> foo; // bar
>
> then I want the cursor to be aligned with foo after hitting Enter. If I
> use CTRL-U or CTRL-W to erase the comment leader then I need to
> reposition the cursor at the right column manually.
>
>
>
If 'cinkeys' contains the "!" flag, then you can press the key specified
for that flag (default is CTRL-F)
in insert mode to reindent the line again. (
https://vimhelp.org/indent.txt.html#i_CTRL-F)
- Yegappan
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Matthijs van Duin
+1 on this, please make this new behaviour optional. I absolutely never ever want a comment leader inserted in this situation (if a statement requires more than one line of comment to clarify, I'd put them on their own above the statement), and it's messing up my muscle memory and making me constantly have to fix what I just typed.
When I type a line of code, with or without a small comment at end of line, and press enter, I continue typing code. My hands are expecting to be able to do that, since that's how it has worked for years and years. These kinds of behaviour changes to input are really disruptive, and moreover most of our systems are running debian stable and therefore will continue to have the old behaviour, so I wouldn't even be able to get used to the change even if I wanted to.
I don't really want to have to resort to patching vim to fix this, especially since I if I do that I'd probably end up never updating it... is there any good workaround to get the old behaviour back?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
> +1 on this, please make this new behaviour optional. I absolutely
>
> When I type a line of code, with or without a small comment at end of
> line, and press enter, I continue typing code. My hands are expecting
> to be able to do that, since that's how it has worked for years and
> years. These kinds of behaviour changes to input are really
> disruptive, and moreover most of our systems are running debian stable
> and therefore will continue to have the old behaviour, so I wouldn't
> even be able to get used to the change even if I wanted to.
>
> I don't really want to have to resort to patching vim to fix this,
> especially since I if I do that I'd probably end up never updating
> it... is there any good workaround to get the old behaviour back?
:setlocal fo-=o
--
From "know your smileys":
|-( Contact lenses, but has lost them
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Bram Moolenaar
After patch 8.2.4907 you can disable this with the "/" flag in 'formatoptions'.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Bram Moolenaar
Closed #10006.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Jonathan Wakely
Awesome, thanks! Time for another donation to ICCF :-)
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Terry Greeniaus
Seriously, practically nobody ever wants this behaviour. It's just not how anybody ever comments code. Changing the default behaviour in favor of the 3 people that do this vs. the 15 million people that don't is... questionable.
I think we will have to go and muck around with .vim/after/* files to get the default behaviour back because the c.vim ftplugin won't have the required "/" flag and it runs after our .vimrc, right? How about instead of adding a disable option for this new feature we make it an enable option instead? Or maybe the default c.vim file can be updated to include the "/" flag by default so that the behaviour doesn't change for literally everybody in the whole world? The commit that resolved this for patch 8.2.4907 isn't linked in this issue so it's hard to see what exactly was done to implement it - if the default c.vim file was updated then my bad!
I am on macOS and unfortunately the c.vim file is protected by macOS's System Integrity Protection so that it can't even be edited (not even with sudo); to get the old and expected behaviour back we would need to get the "/" flag added to c.vim and then Apple to pick up the updated vim and roll it into a future macOS release.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Matthijs van Duin
The commit that resolved this for patch 8.2.4907 isn't linked in this issue
Here: 2bf875f
They're tagged hence easy to find, e.g. https://github.com/vim/vim/commits/v8.2.4907
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Matthijs van Duin
Also, putting set formatoptions+=/ in .vimrc fortunately works just fine... the c.vim ftplugin doesn't completely overwrite formatoptions, it does setlocal fo-=t fo+=croql
—
Reply to this email directly, view it on GitHub.
You are receiving this because you commented.
Gary Johnson
> Seriously, practically nobody ever wants this behaviour. It's just
> not how anybody ever comments code. Changing the default behaviour
> in favor of the 3 people that do this vs. the 15 million people
> that don't is... questionable.
comments. Other than those examples, I have no idea how many people
besides me use them and you don't, either.
> I think we will have to go and muck around with .vim/after/* files
> to get the default behaviour back because the c.vim ftplugin won't
> have the required "/" flag and it runs after our .vimrc, right?
set formatoptions+=/
in your vimrc. $VIMRUNTIME/c.vim sets 'formatoptions' using -= and
+= so that it doesn't affect other flags added to 'formatoptions'
previously.
> How about instead of adding a disable option for this new feature
> we make it an enable option instead? Or maybe the default c.vim
> file can be updated to include the "/" flag by default so that the
> behaviour doesn't change for literally everybody in the whole
> world? The commit that resolved this for patch 8.2.4907 isn't
> linked in this issue so it's hard to see what exactly was done to
> implement it - if the default c.vim file was updated then my bad!
FWIW, at the time it was considered not a new feature but a fix to
a bug in the old behavior. I think that's why it was decided that
the new '/' flag should restore the old behavior rather than enable
the new behavior.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Terry Greeniaus
If I came across as confrontational I apologize. I am comforted to know that I will only have to keep my .vimrc up to date rather than carry around other files with me as well.
@vim-ml, I find it odd to say it's a fix when the behaviour for as long as I have used vim (only around 16 years, granted, and vim is much older) has been to not auto-indent a line following a trailing comment. Also, I think you are confusing style guidelines ("Both the Linux kernel and Vim use multi-line end-of-line comments.") with actually entering code with an editor. If a comment must continue on the next line, then I agree that it should be indented and while I am entering such a comment if I hit the rightmost margin it would be ideal for the text editor to break the comment up into a new line with the automatic indent. Perhaps there is a setting to do that in vim; for me it just allows the line to continue past the width of my terminal so I need to manually break it after completing the over-long line. When I do have such a comment that extends past the rightmost margin and I manually break the line in the middle of the comment, this version of vim does auto-indent it for me which is ideal. So, yay! I did not test an older version of vim to see if this is new behaviour.
However, and this is the big one: if I am typing a trailing comment, and I have not hit the rightmost margin (perhaps I'm nowhere even near it) and I manually hit Enter to put in a line break, it should absolutely never ever ever auto-indent it. And yes, we can come up with an idea of how often this happens. Using the Linux kernel as an example, I ran the following script against commit ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e (which is where my HEAD happened to be and is not the current kernel HEAD):
import argparse
# Trailing comment count: number of lines that had non-whitespace and a
# trailing // comment.
TRAILING_COMMENT_COUNT = 0
# Number of lines that followed a trailing comment which were just whitespace
# followed by // at any indent.
FOLLOWON_COMMENT_COUNT = 0
def main(args):
global TRAILING_COMMENT_COUNT
global FOLLOWON_COMMENT_COUNT
for fpath in args.files:
with open(fpath, 'r', encoding='utf8') as f:
last_was_trailing = False
for l in f:
pre, slashes, post = l.partition('//')
if not slashes:
last_was_trailing = False
elif pre.strip():
TRAILING_COMMENT_COUNT += 1
last_was_trailing = True
elif last_was_trailing:
FOLLOWON_COMMENT_COUNT += 1
else:
last_was_trailing = False
print('Trailing comments: %u' % TRAILING_COMMENT_COUNT)
print('Followon comments: %u' % FOLLOWON_COMMENT_COUNT)
def _main():
parser = argparse.ArgumentParser()
parser.add_argument('files', nargs='+')
args = parser.parse_args()
main(args)
if __name__ == '__main__':
_main()
The script searches for trailing double-slash comments, counts how many of them it finds and then counts how many times the next line(s) are whitespace-delimited comments at any indent. It makes no attempt to see if the followon line's indent actually matches the initial trailing comment's indent, so this is an upper bound on how many followon lines in the kernel could have benefited from an auto-indent.
Here is a stupid test file to make sure it isn't completely wrong:
asdfasdf adsf asdf; // trailing comment
asdfasdf adsf asdf; // trailing comment
asdfasdf adsf asdf; // trailing comment
asdfasdf adsf asdf; // trailing comment
// Single-line comment
// Block comment indented
// asdf asdasdf
// adsfa
// da sdf
// adsf asdfasdfasdf asdf
// a
// sdfasdfadsf
// sdafasdfadsf
asdsdf asfa sdfaf a; // trailing comment
// followon comment
// another followon comment
And the output:
% python3 comment_counter.py test.cc
Trailing comments: 5
Followon comments: 2
And here is the result on the Linux kernel (note that xargs splits up invocations so that there are no more than 5000 arguments passed to the script at a time which is why we get the results multiple times):
% find linux/ -name "*.c" | xargs python3 comment_counter.py
Trailing comments: 718
Followon comments: 0
Trailing comments: 1798
Followon comments: 68
Trailing comments: 1025
Followon comments: 4
Trailing comments: 889
Followon comments: 5
Trailing comments: 1264
Followon comments: 13
Trailing comments: 1285
Followon comments: 19
Trailing comments: 1148
Followon comments: 3
% find linux/ -name "*.h" | xargs python3 comment_counter.py
Trailing comments: 11752
Followon comments: 166
Trailing comments: 7451
Followon comments: 226
Trailing comments: 538
Followon comments: 8
Trailing comments: 633
Followon comments: 1
Trailing comments: 634
Followon comments: 46
And finally, I tabulate the results:
Total trailing comments: 29135
Total followon comments: 559
Percentage of time hitting <Enter> should auto-indent: 1.9186545392140038%
Percentage of time hitting <Enter> should not auto-indent: 98.081345460786%
I claim a >98% rate where the line following a trailing comment in the Linux kernel should not be indented is consistent with "practically nobody ever wants this behaviour". I also withdraw my baseless statistic that 3 people out of 15 million actually desire this behaviour since obviously that is completed unsubstantiated and not helpful to the discussion; hopefully this analysis is more constructive in choosing what the default behaviour should be.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
Gary Johnson
> If I came across as confrontational I apologize. I am comforted to
> know that I will only have to keep my .vimrc up to date rather
> than carry around other files with me as well.
> @vim-ml, I find it odd to say it's a fix when the behaviour for as
> long as I have used vim (only around 16 years, granted, and vim is
> much older) has been to not auto-indent a line following
> a trailing comment.
hoops to get a properly-formatted comment, especially when editing
it to add or remove text from the first line, when Vim should just
know how to do that. And it does now.
> Also, I think you are confusing style guidelines ("Both the Linux
> kernel and Vim use multi-line end-of-line comments.") with
> actually entering code with an editor. If a comment must continue
> on the next line, then I agree that it should be indented and
> while I am entering such a comment if I hit the rightmost margin
> it would be ideal for the text editor to break the comment up into
> a new line with the automatic indent. Perhaps there is a setting
> to do that in vim; for me it just allows the line to continue past
> the width of my terminal so I need to manually break it after
> completing the over-long line.
flags. I'm sorry, I can't find where that's documented. It seems
that if the cursor is to the left of 'textwidth' when you begin
inserting text, text you add will automatically wrap. However, if
you begin inserting to the right of 'textwidth', or you begin to the
left of 'textwidth' and your inserted text does not cross
'textwidth' then the line will not be reformatted even if the total
length exceeds 'textwidth'.
> When I do have such a comment that extends past the rightmost
> margin and I manually break the line in the middle of the comment,
> this version of vim does auto-indent it for me which is ideal. So,
> yay! I did not test an older version of vim to see if this is new
> behaviour.
behavior you're not happy with.
> However, and this is the big one: if I am typing a trailing
> comment, and I have not hit the rightmost margin (perhaps I'm
> nowhere even near it) and I manually hit Enter to put in a line
> break, it should absolutely never ever ever auto-indent it.
r Automatically insert the current comment leader after
hitting <Enter> in Insert mode.
If you don't want that, then you will have to put
setlocal fo-=r
in an after/ftplugin/c.vim, because Vim sets it in
$VIMRUNTIME/ftplugin/c.vim.
> And yes, we can come up with an idea of how often this happens.
> Using the Linux kernel as an example, I ran the following script
> against commit ce522ba9ef7e2d9fb22a39eb3371c0c64e2a433e (which is
> where my HEAD happened to be and is not the current kernel HEAD):
> The script searches for trailing double-slash comments, counts how
> many of them it finds and then counts how many times the next
> line(s) are whitespace-delimited comments at any indent. It makes
> no attempt to see if the followon line's indent actually matches
> the initial trailing comment's indent, so this is an upper bound
> on how many followon lines in the kernel could have benefited from
> an auto-indent.
While I often allow my trailing comments to extend to the next line,
I try to keep them to one line, and I have the 'r' flag set in
'formatoptions', so I should experience this problem, but I don't.
I don't know why. I'll pay more attention to my typing this week.
I have the 'o' flag unset, so it may be that I end one-line trailing
comments with <Esc>o rather than <Enter> and I'm just so used to it
that I don't think about it.
Do you hit <Enter> often enough when typing a block comment for
unsetting the 'r' flag to be a problem?
I think we agree that the new behavior works well when it's
wanted, and that it is sometimes wanted though more often not--the
question is how to control when it is applied.
Regards,
Gary
vim-dev ML
—
Reply to this email directly, view it on GitHub.
You are receiving this because you are subscribed to this thread.
Terry Greeniaus
When I do have such a comment that extends past the rightmost
margin and I manually break the line in the middle of the comment,
this version of vim does auto-indent it for me which is ideal. So,
yay! I did not test an older version of vim to see if this is new
behaviour.
If I understand you correctly, this is the new behavior, the
behavior you're not happy with.
I wasn't clear in that example. Suppose my terminal is set to 80 columns. If I type a comment that extends past 80 columns, the way my vim is configured is that it allows the line to continue past 80 columns by wrapping characters to the next terminal line but without inserting any newlines into the file I am editing. The same as if you enter a really long command on your shell prompt. Then, if I move my cursor backwards along the line to a logical spot and insert a newline manually, vim will now auto-indent it to match. For instance, if I start with some code and a super long comment:
uint8_t
qspi::controller::read_status_register() const
{
uint8_t sr;
exec_101_input(0x05,0,1,&sr); // This is a line with a really really reall
y really really really really really really really really really super duper lon
g comment and the line length is way over 80 characters even way over 160 charac
ters and wraps in my terminal multiple times!
and then manually move the cursor to just after the first "really" and press Enter while in insert mode I get:
uint8_t
qspi::controller::read_status_register() const
{
uint8_t sr;
exec_101_input(0x05,0,1,&sr); // This is a line with a really
// really really really really really really
really really really really really super duper long comment and the line length
is way over 80 characters even way over 160 characters and wraps in my terminal
multiple times!
I think that is the new behaviour and it seems very useful; ideally I would have vim configured to do that automatically if my comment extends past the edge of my terminal.
I will try with those flags you mention and see if they are helpful to me. I do hit Enter in block comments all the time since my config doesn't auto-wrap comments for me. For an example of the other behaviour I'd prefer, here is some code that I just wrote this afternoon:
void
stm32::qspi::start_wip_autopoll() const
{
// Start a 1-0-1 input command to match bit 0.
// Set the period to 65535 clock periods.
regs->cr.set_field(0,4,8); // FTHRES=0
regs->cr.set_bit(22); // APMS=1
regs->cr.set_bit(19); // SMIE=1
regs->fcr = (1 << 3);
regs->dlr = 0;
For the comment at the beginning of the function ("// Start a 1-0-1 input..."), after typing the first line I hit Enter. To me, it's debatable whether the next line should automatically continue the block comment or not, and either behaviour would seem acceptable. vim doesn't really have any way of knowing my intent since I didn't type to the edge of the terminal where it could auto-wrap. I would still want at least a single tab-stop indent though.
The problematic new behaviour comes on the third line of the function body. Here, I am trying to document that the code is setting the "FTHRES" field in some register to 0. When I hit Enter after that comment, I want it to auto-indent just one tab-stop so I can continue writing code rather than auto-indenting all the way up to the same column that "// FTHRES..." started in and auto-inserting the "// " part. On previous versions of vim, it would just do the single tab stop-indent and now it is doing the comment-continuation indent instead forcing a CTRL-U to remove it which I had to do twice while coding the above example. Another place where I find this common is with enum declarations where I often tend to add a short comment for each enum value which the new behaviour makes more difficult.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Matthijs van Duin
I agree that the new behaviour would be the right thing to do when auto-wrapping a comment based on text width (as opposed to explicitly pressing enter). It appears that vim used to never auto-wrap trailing comments even if the c formatoption and textwidth are set, whereas the current version with the new / formatoption enabled is actually completely broken: it wraps to the next line but doesn't insert a comment leader (i.e. it behaves as if you pressed enter).
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Matthijs van Duin
I can now also see why the the new behaviour may have been considered a bug fix: when you have both c and t formatoptions enabled and textwidth set you'd probably run into the problem of trailing comments getting auto-wrapped without comment leader insertion, which I'd certainly consider to be a bug which 6e371ec fixes and the / formatoption unfortunately un-fixes.
I think the new behaviour would also be preferred (probably by everyone) when pressing enter somewhere in the middle of a trailing comment. Just not when pressing end at the end of the line nor when using the o command.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Jonathan Wakely
I think the new behaviour would also be preferred (probably by everyone) when pressing enter somewhere in the middle of a trailing comment. Just not when pressing end at the end of the line nor when using the o command.
Yes, as the original reporter of this issue, that behaviour sounds great to me.
When reflowing a comment (either because of autowrapping due to textwidth, or hitting Enter in the middle of a comment) I agree that continuing the comment by inserting the leader and indenting to the start of the comment would be unsurprising, and probably desired by everybody.
But when hitting Enter at the end of a line (or hitting o), I want to continue "the line". And in my mind, "the line" is a line of code that just happens to have a comment at the end, so i want the next line to be the same: another line of code. If I want a comment at the end, I'll put one after typing some code. So indent to the code on the previous line, and no comment leader. My original objection was that the new behaviour treats code code code; // comment as if it's primarily a comment line, ignoring the fact that it's actually a code line too. It assumes that given a line that is part code and part comment, the comment is what you want on the next line too. And as we all seem to agree, that's not desired by everybody all the time.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Bram Moolenaar
> > I think the new behaviour would also be preferred (probably by
> > everyone) when pressing enter somewhere in the middle of a trailing
> > comment. Just not when pressing end at the end of the line nor when
> > using the o command.
>
> Yes, as the original reporter of this issue, that behaviour sounds
> great to me.
>
> When reflowing a comment (either because of autowrapping due to
> start of the comment would be unsurprising, and probably desired by
> everybody.
>
> that just happens to have a comment at the end, so i want the next
> line to be the same: another line of code. If I want a comment at the
> end, I'll put one after typing some code. So indent to the code on the
> previous line, and no comment leader. My original objection was that
> the new behaviour treats `code code code; // comment` as if it's
> comment, the comment is what you want on the next line too. And as we
> all seem to agree, that's not desired by everybody all the time.
trailing comment on the next line when creating a new line, but I see it
also stops automatic wrapping from working properly. I'll fix that.
The reason to make it work this way was explained several times before:
If the default is to repeat the comment, a simple CTRL-U can remove it
if you don't want it. If the default was to not repeat the comment and
you do want it, you have to manually type the indent and the comment
leader, which is not easy. Especially typing Enter while typing the
comment is ambiguous, it can either mean to insert a line break in the
comment or to start a non-comment line.
--
GALAHAD: Camelot ...
LAUNCELOT: Camelot ...
GAWAIN: It's only a model.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
Christian Brabandt
can you please check 7e66778 (Patch v8.2.5008)?
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Terry Greeniaus
Sorry for the late reply. I'm not sure which behaviour discussed in this thread that you wanted checked in 8.2.5008.
I just installed vim 9.0000 and added the following to my .vimrc file:
set fo+=/
With that in place, it behaves the way I want. The only downside to this is that if I accidentally open my system vim which is 8.2.4113 I now get an error on the console before vim launches:
Error detected while processing /Users/greent7/.vimrc:
line 89:
E539: Illegal character </>: fo+=/
Press ENTER or type command to continue
So, I suppose the '/' option wasn't added until after the change was made. Anyways, it's a minor issue and I won't be using the system vim much after this so I'm okay with it.
Thank you all for your hard work on vim.
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.
Jürgen Krämer
You can wrap the set statement with an if that tests for patch 8.2.5008:
if has('patch-8.2.5008')
set fo+=/
endif
Regards,
Jürgen
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.
Terry Greeniaus
Thanks @jottkaerr, that works great!
—
Reply to this email directly, view it on GitHub.
You are receiving this because you were mentioned.