Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Keven Lyda wrote:

> On Sunday, July 24, 2016 at 2:03:06 PM UTC+1, Bram Moolenaar wrote:
> > Vim has always been conservative about the default option values.
> > Without any .vimrc the default is 'compatible'.  That's nice for people
> > who rely on the old Vi.  But how many of these still exist?  I expect
> > nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> > 
> > What has stopped me from changing this is the unexpected change.  Many
> > users will notice that Vim suddenly behaves differently.  Some may be
> > upset.  The release of Vim 8.0 might be the best point in time to do
> > this.  If we do this.
> 
> So this was unfortunate.

And more than a year ago...
 
> I like the idea of moving forward but kind of bummed how it was done.
> Specifically:
> 
> On Ubuntu the vim8 package has a /etc/vim/vimrc which pulls in a
> /etc/vim/vimrc.local if it exists. With vim8 "set mouse=a" is the
> default when a mouse is detected. And that's fine for lots of folks
> but I'm not a fan so I'd like to disable it system-wide.  So I put
> "set mouse=" in /etc/vim/vimrc.local and I'm good, yes?
> 
> No. No I'm not. It seems that /usr/share/vim/vim80/defaults.vim (which
> was mildly hard to find btw) is sourced after /etc/vim/vimrc and
> /etc/vim/vimrc.local. This seems unfortunate. And yes, I'm aware
> per-user .vimrc's are a thing but I'd rather set this system-wide w/o
> editing the distribution files.
> 
> And that was possible with /etc/vim/vimrc.local but now is not. Is
> this something that could be changed and would it be a vim issue or a
> vim packaging issue?

System-wide Vim initialisation, especialy from a distribution, generally
makes things more complicated.  It's like second guessing the Vim
defaults, and then letting the user figure out what happened.  The help
will show different values, thus the user is confused.

Ubuntu is quite conservitive in /etc/vim/vimrc, this appears to be
coming from Debian.  Lots of comments, what is actually doing something:

runtime! debian.vim

Hmm, this depends on 'runtimepath' which would have to be build into the
executable.  If you compile your own Vim this probably doesn't work.

It triggers the load of /usr/share/vim/vim80/debian.vim, which contains
some random settings that the Debian maintainer apparently prefers.  It
sets 'history' to 50, even though that's already the default.  And turns
on 'ruler', which seems like a random choice.

Then there is:

if has("syntax")
  syntax on
endif

OK, so force syntax highlighting onto all users.  And before loading
color schemes and setting up your own filetypes...

Oh well, if you compile your own Vim then /etc/vim/vimrc most likely
won't be used.

Realy, the system-wide vimrc was meant to be used for system-specific
settings.  E.g. the path of tools, spell files, etc.  Not for user
preferences.

-- 
Friends?  I have lots of friends!  In fact, I have all episodes ever made.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

For me nothing changed. My vimrc used to source the vimrc_example.vim,
it still does, but now vimrc_example.vim just sources the
defaults.vim, which contains what used to be in the vimrc_example.vim.
No sweat.

About system vimrc files, I hate them: in my experience they contain
the misguided and undocumented opinions of some
sysadminBOFH about what is best for me. This is one of
the reasons why I compile my own Vim (so it looks for a system vimrc
at $VIM/vimrc, doesn't find it, and bypasses my distro's system vimrc
at /etc/vimrc). The other reason is that openSUSE's so-called "stable"
version of Vim is unreasonably behind the times (currently 7.4.326).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Christian Brabandt]

On Fr, 10 Nov 2017, Kevin Lyda wrote:

> On Sunday, July 24, 2016 at 2:03:06 PM UTC+1, Bram Moolenaar wrote:
> > Vim has always been conservative about the default option values.
> > Without any .vimrc the default is 'compatible'.  That's nice for people
> > who rely on the old Vi.  But how many of these still exist?  I expect
> > nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> > 
> > What has stopped me from changing this is the unexpected change.  Many
> > users will notice that Vim suddenly behaves differently.  Some may be
> > upset.  The release of Vim 8.0 might be the best point in time to do
> > this.  If we do this.
> 
> So this was unfortunate.
> 
> I like the idea of moving forward but kind of bummed how it was done. 
> Specifically:
> 
> On Ubuntu the vim8 package has a /etc/vim/vimrc which pulls in a 
> /etc/vim/vimrc.local if it exists. With vim8 "set mouse=a" is the default 
> when a mouse is detected. And that's fine for lots of folks but I'm not a fan 
> so I'd like to disable it system-wide.  So I put "set mouse=" in 
> /etc/vim/vimrc.local and I'm good, yes?
> 
> No. No I'm not. It seems that /usr/share/vim/vim80/defaults.vim (which was 
> mildly hard to find btw) is sourced after /etc/vim/vimrc and 
> /etc/vim/vimrc.local. This seems unfortunate. And yes, I'm aware per-user 
> .vimrc's are a thing but I'd rather set this system-wide w/o editing the 
> distribution files.
> 
> And that was possible with /etc/vim/vimrc.local but now is not. Is this 
> something that could be changed and would it be a vim issue or a vim 
> packaging issue?

See the discussion in the following issue:
https://github.com/vim/vim/issues/2042


Christian
-- 
Und die Sonne Homers, siehe! Sie lächelt auch uns.
-- Friedrich Schiller

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Kevin Lyda]

On Sunday, July 24, 2016 at 2:03:06 PM UTC+1, Bram Moolenaar wrote:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> 
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.

So this was unfortunate.

I like the idea of moving forward but kind of bummed how it was done. 
Specifically:

On Ubuntu the vim8 package has a /etc/vim/vimrc which pulls in a 
/etc/vim/vimrc.local if it exists. With vim8 "set mouse=a" is the default when 
a mouse is detected. And that's fine for lots of folks but I'm not a fan so I'd 
like to disable it system-wide.  So I put "set mouse=" in /etc/vim/vimrc.local 
and I'm good, yes?

No. No I'm not. It seems that /usr/share/vim/vim80/defaults.vim (which was 
mildly hard to find btw) is sourced after /etc/vim/vimrc and 
/etc/vim/vimrc.local. This seems unfortunate. And yes, I'm aware per-user 
.vimrc's are a thing but I'd rather set this system-wide w/o editing the 
distribution files.

And that was possible with /etc/vim/vimrc.local but now is not. Is this 
something that could be changed and would it be a vim issue or a vim packaging 
issue?

Kevin

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Michael Henry]

On 08/20/2016 01:22 PM, Bram Moolenaar wrote:
> Hirohito Higashi wrote:
>> `set ttimeoutlen=0` will solve the above.
>>
>> I have invested in above setting more than a year, but the
>> trouble does not happen even once.
>
> Zero only works when you are directly using a terminal.  When
> using a remote shell it might not work properly.  But one
> second is indeed too much.
>
> I have it set to 200, this still has some lag.  I think 100
> would work for just about everyone.

I ran for a long time without trouble using 50 milliseconds.
But even this eventually proved too long once I began using
Alt-letter mappings in console Vim.  The key sequence for Alt-j
is j.  I would frequently press  to exit insert mode
followed quickly by the j key, and Vim would misinterpret the
sequence as Alt-j (which would then invoke my insert-mode
mapping for Alt-j).  I found experimentally that I could set
ttimeoutlen to 5 to avoid most instances of this kind of
incorrect key interpretation.  This value has never proved to be
too small in my use.  I've never noticed a case of Vim timing
out in the middle of a valid multi-key sequence and splitting it
incorrectly into multiple keypresses, even when using Vim across
an SSH connection; however, these connections were typically
done over a local Ethernet, so on a slower network it's possible
that such splitting could occur (such that Alt-j might be split
erroneously into  followed by j).  I consider this an
unlikely case, since the multi-key sequence will probably be
written to the network as a unit and carried in a single network
packet, regardless of the speed of the network; still, until we
start using uniquely decodable key sequences so we don't have to
rely on timeouts, there will always be some risk of incorrect
key interpretation.

I think 100ms is better than 200ms as a default.  I wouldn't
suggest a default as low as 5ms due to the possible risk of
misinterpreting multi-byte key sequences, even though I've never
personally noticed such a failure.  Users like myself who
require shorter values can always override the default.  I'll
also note that I've seen 100ms used elsewhere, such as in Tim
Pope's "Sensible Defaults" plugin:
https://github.com/tpope/vim-sensible/blob/master/plugin/sensible.vim#L28

Michael Henry

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Hirohito Higashi wrote:

> Sorry for late reply :-)
> 
> I want to add the following setting:
> 
>   " If Vim cause malfunctioning cursor keys on slow terminals or very busy 
> systems, adjust the value or comment out this.
>   set ttimeoutlen=0
> 
> 'ttimeoutlen' default value is -1.
> This means that use the 'timeoutlen' to the key code time-out value.
> That one second.
> I think most user feels "Vim is slow" in the following operation.  This is 
> disadvantage.
> - When the transition to the normal-mode by pressing the XXX in insert-mode.
>   i
> - Similarly, in visual-mode.
>   V
> - Similarly, in cmdline-mode.
>   :
> 
> Yes, I know that lag does not occur if the input without waiting for
> the display is switched.
> But, most people would wait until the display is switched.  And they
> feels "Vim is slow...".
> 
> `set ttimeoutlen=0` will solve the above.
> 
> I have invested in above setting more than a year, but the trouble
> does not happen even once.

Zero only works when you are directly using a terminal.  When using a
remote shell it might not work properly.  But one second is indeed too
much.

I have it set to 200, this still has some lag.  I think 100 would work
for just about everyone.

-- 
Latest survey shows that 3 out of 4 people make up 75% of the
world's population.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

"map Q gq" has long been part of the vimrc_example.vim. Now it is
moved to defaults.vim which vimrc_example.vim sources. So if you have
a vimrc you won't be affected, even if your own vimrc sources the
vimrc_example.vim, because in that case you already had it and will
keep it. If, like me, you don't like this mapping, you'll do what I've
long been doing: unmap Q at some point after sourcing the
vimrc_example.vim.

This mapping will, in fact, only apply to you if you were relying on
the absence of a vimrc to get a legacy-vi-like 'compatible'
environment. In that case it might be time to set up an empty exrc
file, which IIUC will also leave 'compatible' set, avoid sourcing
defaults.vim, and do nothing else.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Martin Lundberg]

On Thursday, July 28, 2016 at 4:32:31 PM UTC+2, ZyX wrote:
> You can’t. “At the same time” may mean both “ pressed slightly
> after  press  after  is in par with `Q`: `g` and `q` use different fingers and they need to
> be pressed in specific sequence as well. `Q` may actually be worse if
> you are trying to press this as fast as possible: you must release  after pressing , but it does not matter when you release  and
> , only when you press them matters.
> 
> Also depends on keyboard and layout: dvorak has  and  on
> different hands, while  and  is harder to use on my keyboard because it has <\> before it which is
> not uncommon, so I tend to avoid it, mostly using for `":<>` (us:
> `ZQWE`), even A (us: A, one of two keys which match in us and dvorak
> layouts) is typed using left shift).
> 
> Note: unlike @Martin Lundberg I see that typing `gq` using *two* hands
> is *faster* then typing `Q` using *one*. I tried and can type `Q` with
> two hands faster then with one, but this makes following text slower
> (both because I am not used and because restoring little finger
> position from far  text follows `Q`).
> 
> And, if I am not mistaking, requirement to *switch* hands for common
> letter combinations is one of the reasons why typing with dvorak is
> *faster*. So “involving two hands” could be a word for `Q`, not for me
> though due to my far right shift.

It's also not just about hitting gq or Shift-Q but being ready for the motion 
too. I mostyly do gqj, gqip, etc and that is a lot faster when not moving for 
SHIFT. However as Bram said, people who has a .vimrc won't be affected and if 
I'm the only one feeling like this then nevermind :)

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

I wrote:

[...]

> Another solution: When there is a .vimrc, then don't load startup.vim.
> Rely on the user already have his preferences in the .vimrc.
> Thus only apply these better defaults when the user doesn't have his own
> settings.  Ah, I see Ben also had this idea.
> 
> The more I think about it, the more this seems like a good solution:
> - If the user has a .vimrc, use that.
> - If there is no .vimrc, use the default .vimrc.
> - When a new user creates a .vimrc, he can source the default one or
>   copy it.  It's possible to do settings before this, such as adding 'M'
>   to 'guioptions'.
> 
> That way anybody which already has a .vimrc isn't bothered by different
> defaults.  100% backwards compatible.
> 
> New users will get better defaults.  When using Vim on a new system it
> also has better defaults.
> 
> Only those who really want the Vi defaults or the Vim 7 defaults would
> need to create a .vimrc and set 'compatible' or 'nocompatible'.
> 
> There is some confusion for users who create their .vimrc for the
> first time and don't know about the default vimrc.  That can be
> documented and once discovered it's easy to fix.

I haven't heard negative comments for this idea, I'll interpret that as a
positive response.  I suppose all of the readers here have a .vimrc,
thus won't be affected by the change.  And new users will like (most of)
the new defaults.

I'll send out a patch to do it this way.  We can fine tune after that.

-- 
If an elephant is left tied to a parking meter, the parking fee has to be paid
just as it would for a vehicle.
[real standing law in Florida, United States of America]

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Nikolay Aleksandrovich Pavlov]

2016-07-28 16:58 GMT+03:00 Bram Moolenaar :
>
> Martin Lundberg wrote:
>
>> On Tuesday, July 26, 2016 at 11:18:01 PM UTC+2, Bram Moolenaar wrote:
>> > " Don't use Ex mode, use Q for formatting
>> > map Q gq
>>
>> What's the reason for doing this change when the new mapping has just
>> as much key presses? For me it actually feels like it's slower than gq
>> since I need to involve and move both hands.
>>
>> I can see in the help for gq that Q actually did gq before which could
>> be a reason to change it back but I guess there was a reason for
>> changing it to gq too?
>
> It's an old alias for formatting.  "Q" was made Posix compatible at some
> point to make it pass some tests.
>
> I don't see Q as two key strokes, I have two fingers that I can use at
> the same time.

You can’t. “At the same time” may mean both “ pressed slightly
after ` (us:
`ZQWE`), even A (us: A, one of two keys which match in us and dvorak
layouts) is typed using left shift).

Note: unlike @Martin Lundberg I see that typing `gq` using *two* hands
is *faster* then typing `Q` using *one*. I tried and can type `Q` with
two hands faster then with one, but this makes following text slower
(both because I am not used and because restoring little finger
position from far 
> --
> BEDEVERE: How do you know so much about swallows?
> ARTHUR:   Well you have to know these things when you're a king, you know.
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:31 PM, Kazunobu Kuriyama <
kazunobu.kuriy...@gmail.com> wrote:

>
> It may be true that setting go+=M will reduce memory usage and make
> startup faster.  But I would say the benefit gained by doing that is quite
> marginal.
>

It makes a noticeable difference to me.  That's part of why I do it.


> Hence, in comparison with those heavy tasks, what is gained by go+=M is
> negligible.
>

That's not the only reason someone would want to disable the system menus.
Some users just don't want to stare at all that garbage.  It's the *same*
justification for the existence of *tons* of other options.

I disable the system menu.vim so that I can source my own custom version
that's very bare-bones.  It doesn't cause a noticeable speedup and my
screen is uncluttered.  Thus the gain by having go+=M is not negligible.


> I don't understand why go+=M is so important for some people.
>

I don't understand why suddenly having a system vimrc after years with none
is so important for some people.  Nor do I understand why, if we're going
to have one, some people are so desperate that "syntax on" and "filetype
blah" be in it.  Is it that important to be able to delete one or two lines
that are proably already in your vimrc?

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Gary Johnson wrote:

> [...]
> 
> Not all of those would be my preference, but they seem reasonable,
> and as long as all of that is in a file and the compile-time
> defaults aren't changed, I'm fine with it.
> 
> I was surprised by this:
> 
> > " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> > " let  = substitute(, "t", "", "g")
> 
> Why substitute() instead of just -=?
> 
> set guioptions-=t

Yeah, and why is it commented out?  Actually, why don't we make this the
default?  I don't think anybody on MS-Windows wants tear-off menus,
unless you know them from Unix perhaps.

-- 
ROBIN:  (warily) And if you get a question wrong?
ARTHUR: You are cast into the Gorge of Eternal Peril.
ROBIN:  Oh ... wacho!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Manuel Ortega wrote:

> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
> wrote:
> 
> > On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
> > wrote:
> >
> >>
> >>
> >> " Switch syntax highlighting on when the terminal has colors or when
> >> using the
> >> " GUI (which always has colors).
> >> if _Co > 2 || has("gui_running")
> >>   syntax on
> >>
> >
> > Wait a sec.  If "syntax on" is done here, then won't it be impossible to
> > use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
> > say that in order for that to work, it must be done "before switching on
> > syntax or filetype recognition".  But if syntax is turned on here, by the
> > time the  "set go+=M" in his .vimrc is encountered it will be too late,
> > right?
> 
> Indeed, that is the case (I tried it).  If you put "syntax on" in the
> system vimrc, then the user cannot use "set go+=M".   I think this is a
> good reason to remove "syntax on" from the proposal.  If it's left in, you
> might as well just eliminate "M" as one of the guioptions, because it's
> totally unusable unless it goes in the local machine's system vimrc, which
> many users will not be able to change, or will not want to tweak it every
> time they build a new Vim.

Thanks for mentioning this.

I don't think the solution is to not enable syntax highlighting, but
do this in another way.  But how?

The trick to do something in an ftdetect script smells like a hack.

Perhaps part of the defaults can be set before loading the .vimrc, so
that they can be overruled, and others can be done after loading the
.vimrc, so that they can be disabled.

Could also move loading menu.vim out of filetype.vim, but it's hard to
predict what side effects this has.  E.g. if someone enables filetype
detection and then deletes a menu.  That would break.


Another solution: When there is a .vimrc, then don't load startup.vim.
Rely on the user already have his preferences in the .vimrc.
Thus only apply these better defaults when the user doesn't have his own
settings.  Ah, I see Ben also had this idea.

The more I think about it, the more this seems like a good solution:
- If the user has a .vimrc, use that.
- If there is no .vimrc, use the default .vimrc.
- When a new user creates a .vimrc, he can source the default one or
  copy it.  It's possible to do settings before this, such as adding 'M'
  to 'guioptions'.

That way anybody which already has a .vimrc isn't bothered by different
defaults.  100% backwards compatible.

New users will get better defaults.  When using Vim on a new system it
also has better defaults.

Only those who really want the Vi defaults or the Vim 7 defaults would
need to create a .vimrc and set 'compatible' or 'nocompatible'.

There is some confusion for users who create their .vimrc for the
first time and don't know about the default vimrc.  That can be
documented and once discovered it's easy to fix.


-- 
Sorry, no fortune today.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

Perhaps another way to fix this would be if the user could have a
~/.vim/menu.vim that is treated like ~/.vim/filetype.vim is treated.  I.e.,
that Vim will load the ~/.vim/menu.vim before it loads
$VIMRUNTIME/menu.vim.  That way, a user could in his own ~/.vim/menu.vim
set some variables that will cause most or all of the $VIMRUNTIME/menu.vim
to be skipped.  No need for +=M.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 1:47 PM, Gary Johnson  wrote:

> On 2016-07-27, Manuel Ortega wrote:
> > On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
> >
> > On 2016-07-27, Manuel Ortega wrote:
> >
> > > What if "syntax on" and "filetype plugin indent on" were moved
> into the
> > autocmd
> > > group "vimStartup" that the proposed system vimrc defines, under
> VimEnter
> > > autocmds:
> > >
> > > au VimEnter * syntax on
> > > au VimEnter * filetype plugin on
> > >
> > > This way, everyone who wants them still gets them, and +=M
> still works
> > > without modification.  As an added bonus, both of the "ons" can be
> > prevented
> > > from ever happening using the same "au!" line that kills the
> others in
> > that
> > > group.
> >
> > From ":help VimEnter", the VimEnter event occurs 'After doing all
> > the startup stuff, including loading .vimrc files, executing the
> > "-c cmd" arguments, creating all windows and loading the buffers in
> > them.'
> >
> > Enabling filetype detection after buffers are loaded is too late.
> >
> >
> > Filetype *detection* is on by default in Vim.  It's not being "turned
> on" by
> > "filetype plugin indent on".  So what you say will be too late is not too
> > late.
>
> What makes you think filetype detection is on by default?  That's
> not what I observe.


Because all the files I tested it with had modelines and like an idiot I
forgot about that.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 7:47 PM, Gary Johnson  wrote:
> On 2016-07-27, Manuel Ortega wrote:
>> On Wed, Jul 27, 2016 at 12:26 PM, Gary Johnson wrote:
>>
>> On 2016-07-27, Manuel Ortega wrote:
>>
>> > What if "syntax on" and "filetype plugin indent on" were moved into the
>> autocmd
>> > group "vimStartup" that the proposed system vimrc defines, under 
>> VimEnter
>> > autocmds:
>> >
>> > au VimEnter * syntax on
>> > au VimEnter * filetype plugin on
>> >
>> > This way, everyone who wants them still gets them, and +=M still 
>> works
>> > without modification.  As an added bonus, both of the "ons" can be
>> prevented
>> > from ever happening using the same "au!" line that kills the others in
>> that
>> > group.
>>
>> From ":help VimEnter", the VimEnter event occurs 'After doing all
>> the startup stuff, including loading .vimrc files, executing the
>> "-c cmd" arguments, creating all windows and loading the buffers in
>> them.'
>>
>> Enabling filetype detection after buffers are loaded is too late.
>>
>>
>> Filetype *detection* is on by default in Vim.  It's not being "turned on" by
>> "filetype plugin indent on".  So what you say will be too late is not too
>> late.
>
> What makes you think filetype detection is on by default?  That's
> not what I observe.
>
> $ vim -N -u /dev/null hello.c
> :set ft?
>   filetype=
>
> It is turned on by "filetype [args] on" and by "syntax on".
>
> Regards,
> Gary

Indeed: filetype detection is turned on by the vimrc_example.vim, but
it is neither the 'compatible' nor the 'nocompatible' default in the
absence of startup scripts (i.e. neither "vim -u NONE" nor "vim -u
NONE -N" have it. Even "vim -u NORC -N" i.e., no vimrc but with global
plugins and 'nocompatible' doesn't set it.)

To get a reproducible setup with filetype detection, you might want to
do something like

vim -u /usr/local/share/vim/vim74/vimrc_example.vim

(no need to use -N in this case because the vimrc_example.vim sets it.)


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 8:00 PM, Gary Johnson  wrote:
> On 2016-07-27, Tony Mechelynck wrote:
>> On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote:
>> > On 2016-07-27, Manuel Ortega wrote:
>> >
>> >> If "syntax on" is in the system vimrc as proposed, then I can't seem to 
>> >> find
>> >> any way *at all* to disable the loading of the system menu.vim (short of
>> >> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>> >
>> > How about "sudo rm /usr/share/vim/vimrc"?
>> >
>> > Another, less drastic way would be to create a file,
>> > ~/.vim/ftdetect/guioptions.vim, containing this:
>> >
>> > set guioptions+=M
>> >
>> > Regards,
>> > Gary
>>
>> That ftdetect/guioptions.vim would, with current Vim, be sourced from
>> $VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
>> only _after_ filetype detection has been set, which is too late for
>> clearing menus, unless you first set ":filetype off". But then you
>> would have to run ":filetype on" afterwards _only_ if it was
>> originally on.
>
> Apparently that's not true:  it's not too late.
>
> Here are the initial lines from :scriptnames:
>
>   1: ~/.vimrc
>   2: ~/.vim/filetype.vim
>   3: /usr/local/share/vim/vim74/filetype.vim
>   4: ~/.vim/ftdetect/csv.vim
>   5: ~/.vim/ftdetect/mediawiki.vim
>   6: /usr/local/share/vim/vim74/menu.vim
>   7: /usr/local/share/vim/vim74/autoload/paste.vim
>   8: /usr/local/share/vim/vim74/ftplugin.vim
>   9: /usr/local/share/vim/vim74/indent.vim
>  10: /usr/local/share/vim/vim74/syntax/manual.vim
>  11: /usr/local/share/vim/vim74/syntax/synload.vim
>  12: /usr/local/share/vim/vim74/syntax/syncolor.vim
>
> You can see that the files in ~/.vim/ftdetect are sourced before
> menu.vim, and in fact are sourced before the decision to source
> menu.vim is made.  I verified that putting "set guioptions+=M" into
> ~/.vim/ftdetect/guioptions.vim would work before posting that
> solution.
>
> Regards,
> Gary

Oops, you're right, it is just in time, but barely.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-27, Tony Mechelynck wrote:
> On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson wrote:
> > On 2016-07-27, Manuel Ortega wrote:
> >
> >> If "syntax on" is in the system vimrc as proposed, then I can't seem to 
> >> find
> >> any way *at all* to disable the loading of the system menu.vim (short of
> >> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
> >
> > How about "sudo rm /usr/share/vim/vimrc"?
> >
> > Another, less drastic way would be to create a file,
> > ~/.vim/ftdetect/guioptions.vim, containing this:
> >
> > set guioptions+=M
> >
> > Regards,
> > Gary
> 
> That ftdetect/guioptions.vim would, with current Vim, be sourced from
> $VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
> only _after_ filetype detection has been set, which is too late for
> clearing menus, unless you first set ":filetype off". But then you
> would have to run ":filetype on" afterwards _only_ if it was
> originally on.

Apparently that's not true:  it's not too late.

Here are the initial lines from :scriptnames:

  1: ~/.vimrc
  2: ~/.vim/filetype.vim
  3: /usr/local/share/vim/vim74/filetype.vim
  4: ~/.vim/ftdetect/csv.vim
  5: ~/.vim/ftdetect/mediawiki.vim
  6: /usr/local/share/vim/vim74/menu.vim
  7: /usr/local/share/vim/vim74/autoload/paste.vim
  8: /usr/local/share/vim/vim74/ftplugin.vim
  9: /usr/local/share/vim/vim74/indent.vim
 10: /usr/local/share/vim/vim74/syntax/manual.vim
 11: /usr/local/share/vim/vim74/syntax/synload.vim
 12: /usr/local/share/vim/vim74/syntax/syncolor.vim

You can see that the files in ~/.vim/ftdetect are sourced before
menu.vim, and in fact are sourced before the decision to source
menu.vim is made.  I verified that putting "set guioptions+=M" into
~/.vim/ftdetect/guioptions.vim would work before posting that
solution.

Regards,
Gary

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Wed, Jul 27, 2016 at 4:43 PM, Gary Johnson  wrote:
> On 2016-07-27, Manuel Ortega wrote:
>
>> If "syntax on" is in the system vimrc as proposed, then I can't seem to find
>> any way *at all* to disable the loading of the system menu.vim (short of
>> unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>
> How about "sudo rm /usr/share/vim/vimrc"?
>
> Another, less drastic way would be to create a file,
> ~/.vim/ftdetect/guioptions.vim, containing this:
>
> set guioptions+=M
>
> Regards,
> Gary

That ftdetect/guioptions.vim would, with current Vim, be sourced from
$VIMRUNTIME/filetype.vim (at current line 2730, near the end), i.e.
only _after_ filetype detection has been set, which is too late for
clearing menus, unless you first set ":filetype off". But then you
would have to run ":filetype on" afterwards _only_ if it was
originally on.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-27, Manuel Ortega wrote:

> What if "syntax on" and "filetype plugin indent on" were moved into the 
> autocmd
> group "vimStartup" that the proposed system vimrc defines, under VimEnter
> autocmds:
> 
> au VimEnter * syntax on
> au VimEnter * filetype plugin on
> 
> This way, everyone who wants them still gets them, and +=M still works
> without modification.  As an added bonus, both of the "ons" can be prevented
> from ever happening using the same "au!" line that kills the others in that
> group.

>From ":help VimEnter", the VimEnter event occurs 'After doing all
the startup stuff, including loading .vimrc files, executing the
"-c cmd" arguments, creating all windows and loading the buffers in
them.'

Enabling filetype detection after buffers are loaded is too late.

I suppose you do that and add something like this:

au VimEnter * bufdo filetype detect

I haven't thought that all the way through.

Regards,
Gary

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 11:40 AM, Manuel Ortega 
wrote:

>
>> I agree that "syntax on" and "filetype on" (maybe even "filetype plugin
>> indent on") are pretty core features that should probably be enabled by
>> default, as nearly everyone will use them.
>>
>
>
>> However, I disagree that this should come at the expense of being able
>> to set up specific options. Anything done in the default settings should
>> be modifiable by the user, and it looks like in this situation that is
>> not possible, if the default settings are always sourced.
>>
>
> I would have no problem with "syntax on" going in a system vimrc if it
> didn't have unfixable side-effects.
>
> Perhaps it's possible for Bram to change the behavior of "syntax on" so
> that it doesn't cause menu.vim to be loaded.  Same for "filetype on".
>
> Or perhaps it's possible for Bram to change them so that menu.vim isn't
> loaded until after the user's vimrc is loaded.  Then the user could at
> least set the "did_install_*" variables.
>
> -Manny
>

What if "syntax on" and "filetype plugin indent on" were moved into the
autocmd group "vimStartup" that the proposed system vimrc defines, under
VimEnter autocmds:

au VimEnter * syntax on
au VimEnter * filetype plugin on

This way, everyone who wants them still gets them, and +=M still works
without modification.  As an added bonus, both of the "ons" can be
prevented from ever happening using the same "au!" line that kills the
others in that group.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[James McCoy]

On Jul 27, 2016 6:20 AM, "Kazunobu Kuriyama" 
wrote:
>
> 2016-07-27 17:01 GMT+09:00 Manuel Ortega :
>> If "syntax on" is in the system vimrc as proposed, then I can't seem to
find any way *at all* to disable the loading of the system menu.vim (short
of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)
>>
>> Not only that, but the variables in menu.vim intended to be settable by
the user to stop certain segments from loading, i.e.,
>>
>> let did_install_default_menus = 1
>> let no_buffers_menu =1
>> let did_install_syntax_menu = 1
>>
>> ... have no effect in the user's vimrc because menu.vim is already
loaded by the system vimrc's "syntax on".
>>
>> Please, please, remove "syntax on" from the proposal.  There is no way
for the user to undo its side-effects.
>>
>> -Manny
>
>
> Hi,
>
> After having read your argument through, I’m still for ‘syntax on’.
>
> After all, the problem boils down to this: How many GUI users do they
actually set go=+M?
>
> My bet is that the number is nearly zero.
>
> If our system menu were of such less importance that one could kill it at
will, it would not be worth being called “the system menu.”

I'd wager it's more than you think. I know many people that change gvim to
basically look like console vim. Personally, I set 'guioptions' to just
"cM".

Cheers,
James

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 3:51 AM, Manuel Ortega 
wrote:

> On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
> wrote:
>
>> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
>> wrote:
>>
>>>
>>>
>>> " Switch syntax highlighting on when the terminal has colors or when
>>> using the
>>> " GUI (which always has colors).
>>> if _Co > 2 || has("gui_running")
>>>   syntax on
>>>
>>
>> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
>> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
>> say that in order for that to work, it must be done "before switching on
>> syntax or filetype recognition".  But if syntax is turned on here, by the
>> time the  "set go+=M" in his .vimrc is encountered it will be too late,
>> right?
>>
>
> Indeed, that is the case (I tried it).  If you put "syntax on" in the
> system vimrc, then the user cannot use "set go+=M".   I think this is a
> good reason to remove "syntax on" from the proposal.  If it's left in, you
> might as well just eliminate "M" as one of the guioptions, because it's
> totally unusable unless it goes in the local machine's system vimrc, which
> many users will not be able to change, or will not want to tweak it every
> time they build a new Vim.
>

If "syntax on" is in the system vimrc as proposed, then I can't seem to
find any way *at all* to disable the loading of the system menu.vim (short
of unacceptable hacks like bash-aliasing 'vim' to 'vim -u ~/.vimrc'.)

Not only that, but the variables in menu.vim intended to be settable by the
user to stop certain segments from loading, i.e.,

let did_install_default_menus = 1
let no_buffers_menu =1
let did_install_syntax_menu = 1

... have no effect in the user's vimrc because menu.vim is already loaded
by the system vimrc's "syntax on".

Please, please, remove "syntax on" from the proposal.  There is no way for
the user to undo its side-effects.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Wed, Jul 27, 2016 at 2:51 AM, Manuel Ortega 
wrote:

> On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar 
> wrote:
>
>>
>>
>> " Switch syntax highlighting on when the terminal has colors or when
>> using the
>> " GUI (which always has colors).
>> if _Co > 2 || has("gui_running")
>>   syntax on
>>
>
> Wait a sec.  If "syntax on" is done here, then won't it be impossible to
> use "set guioptions+=M" in the user's .vimrc and have it work?  The docs
> say that in order for that to work, it must be done "before switching on
> syntax or filetype recognition".  But if syntax is turned on here, by the
> time the  "set go+=M" in his .vimrc is encountered it will be too late,
> right?
>

Indeed, that is the case (I tried it).  If you put "syntax on" in the
system vimrc, then the user cannot use "set go+=M".   I think this is a
good reason to remove "syntax on" from the proposal.  If it's left in, you
might as well just eliminate "M" as one of the guioptions, because it's
totally unusable unless it goes in the local machine's system vimrc, which
many users will not be able to change, or will not want to tweak it every
time they build a new Vim.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Tue, Jul 26, 2016 at 5:17 PM, Bram Moolenaar  wrote:

>
> " Only do this part when compiled with support for autocommands.
> if has("autocmd")
>
>   " Enable file type detection.
>   " Use the default filetype settings, so that mail gets 'tw' set to 72,
>   " 'cindent' is on in C files, etc.
>   " Also load indent files, to automatically do language-dependent
> indenting.
>   filetype plugin indent on
>

This is a plea to not enable ftplugins.  They make using vim analogous to
driving a car whose mirrors, seat adjustment, and radio station keep
automatically changing depending on what direction the car is pointing.

I like that none of this will happen with '-u NONE'.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-26, Bram Moolenaar wrote:
> Gary Johnson wrote:
> 
> > On 2016-07-26, Bram Moolenaar wrote:
> > > James McCoy wrote:
> > > 
> > > > On Mon, Jul 25, 2016 at 07:39:55AM -0700, Ben Fritz wrote:
> > > > > On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> > > > > > 
> > > > > >   if has("autocmd")
> > > > > > " Enable file type detection.
> > > > > > filetype plugin indent on
> > > > > >   
> > > > > 
> > > > > Don't common plugin managers require you to turn on filetype stuff at
> > > > > a very specific location, e.g. *after* loading the plugin manager
> > > > > functionality?
> > > > 
> > > > By now, most of them do this automatically, but I still advocate against
> > > > doing this before the vimrc is loaded since it causes non-obvious
> > > > problems to users (and am annoyed that Ubuntu deviates from the way I've
> > > > setup Debian's packaging in this regard).
> > > > 
> > > > The reason this needs to be done is to for ftdetect scripts.
> > > > 
> > > > Without doing the equivalent of
> > > > 
> > > >   :filetype off
> > > >   " Setup plugin manager
> > > >   " Re-run :filetype on, if needed
> > > > 
> > > > any ftdetect scripts located in the runtime paths handled by the plugin
> > > > manager wouldn't have their settings applied.
> > > > 
> > > > Now, in Neovim we've enable filetype plugins and indent scripts by
> > > > default.  However, we also track whether they were enabled
> > > > automatically, or modified by the user, so that "filetype plugin on" in
> > > > the user's vimrc only enables plugins instead of acting like a no-op.
> > > > You can see the discussion of the behavior/implementation at
> > > > .
> > > 
> > > Arent't users already executing the filetype command early in their
> > > .vimrc?
> > 
> > No.  I execute the filetype command late in my vimrc so that some of
> > my BufRead autocommands will be executed before Vim's.  I want
> > buffers to be initially configured by project, which means looking
> > at the full path to the file being opened, and then by filetype.
> > 
> > I turn _off_ filetype detection near the top of my vimrc in
> > environments where it's been turned on in some system vimrc.
> 
> Hmm, this very much depends on what you want to do in your .vimrc.
> I think it's still best to enable filetype detection when there is no
> .vimrc at all.  And I suspect doing what you do, disabling filetype
> detection at the start of your .vimrc allows for any sequence that you
> choose.
> 
> 
> Here is what I have come up with, listenting to the comments so far and
> giving it some magic weighing:

[...]

Not all of those would be my preference, but they seem reasonable,
and as long as all of that is in a file and the compile-time
defaults aren't changed, I'm fine with it.

I was surprised by this:

> " For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
> " let  = substitute(, "t", "", "g")

Why substitute() instead of just -=?

set guioptions-=t

Regards,
Gary

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Gary Johnson wrote:

> On 2016-07-26, Bram Moolenaar wrote:
> > James McCoy wrote:
> > 
> > > On Mon, Jul 25, 2016 at 07:39:55AM -0700, Ben Fritz wrote:
> > > > On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> > > > > 
> > > > >   if has("autocmd")
> > > > > " Enable file type detection.
> > > > > filetype plugin indent on
> > > > >   
> > > > 
> > > > Don't common plugin managers require you to turn on filetype stuff at
> > > > a very specific location, e.g. *after* loading the plugin manager
> > > > functionality?
> > > 
> > > By now, most of them do this automatically, but I still advocate against
> > > doing this before the vimrc is loaded since it causes non-obvious
> > > problems to users (and am annoyed that Ubuntu deviates from the way I've
> > > setup Debian's packaging in this regard).
> > > 
> > > The reason this needs to be done is to for ftdetect scripts.
> > > 
> > > Without doing the equivalent of
> > > 
> > >   :filetype off
> > >   " Setup plugin manager
> > >   " Re-run :filetype on, if needed
> > > 
> > > any ftdetect scripts located in the runtime paths handled by the plugin
> > > manager wouldn't have their settings applied.
> > > 
> > > Now, in Neovim we've enable filetype plugins and indent scripts by
> > > default.  However, we also track whether they were enabled
> > > automatically, or modified by the user, so that "filetype plugin on" in
> > > the user's vimrc only enables plugins instead of acting like a no-op.
> > > You can see the discussion of the behavior/implementation at
> > > .
> > 
> > Arent't users already executing the filetype command early in their
> > .vimrc?
> 
> No.  I execute the filetype command late in my vimrc so that some of
> my BufRead autocommands will be executed before Vim's.  I want
> buffers to be initially configured by project, which means looking
> at the full path to the file being opened, and then by filetype.
> 
> I turn _off_ filetype detection near the top of my vimrc in
> environments where it's been turned on in some system vimrc.

Hmm, this very much depends on what you want to do in your .vimrc.
I think it's still best to enable filetype detection when there is no
.vimrc at all.  And I suspect doing what you do, disabling filetype
detection at the start of your .vimrc allows for any sequence that you
choose.


Here is what I have come up with, listenting to the comments so far and
giving it some magic weighing:


" The startup file file.
"
" Maintainer:   Bram Moolenaar 
" Last change:  2016 Jul 25
"
" This is loaded very early on startup, execpt with Vim is run with "-u NONE".

" When started as "evim", evim.vim will already have done these settings.
if v:progname =~? "evim"
  finish
endif

" Use Vim settings, rather than Vi settings (much better!).
" This must be first, because it changes other options as a side effect.
set nocompatible

" allow backspacing over everything in insert mode
set backspace=indent,eol,start

set history=200 " keep 200 lines of command line history
set ruler   " show the cursor position all the time
set showcmd " display incomplete commands
set wildmenu" display completion matches in a status line

" Do incremental searching when it's possible to timeout.
if has('reltime')
  set incsearch
endif

" Do not recognize octal numbers for Ctrl-A and Ctrl-X, most users find it
" confusing.
set nrformat-=octal

" For Win32 GUI: remove 't' flag from 'guioptions': no tearoff menu entries
" let  = substitute(, "t", "", "g")

" Don't use Ex mode, use Q for formatting
map Q gq

" CTRL-U in insert mode deletes a lot.  Use CTRL-G u to first break undo,
" so that you can undo CTRL-U after inserting a line break.
inoremap  u

" In many terminal emulators the mouse works just fine.  By enabling it you
" can position the cursor, Visually select and scroll with the mouse.
if has('mouse')
  set mouse=a
endif

" Switch syntax highlighting on when the terminal has colors or when using the
" GUI (which always has colors).
if _Co > 2 || has("gui_running")
  syntax on

  " I like highlighting strings inside C comments.
  let c_comment_strings=1
endif

" Only do this part when compiled with support for autocommands.
if has("autocmd")

  " Enable file type detection.
  " Use the default filetype settings, so that mail gets 'tw' set to 72,
  " 'cindent' is on in C files, etc.
  " Also load indent files, to automatically do language-dependent indenting.
  filetype plugin indent on

  " Put these in an autocmd group, so that we can delete them easily with:
  " augroup vimStartup | au! | augroup END
  augroup vimStartup
  au!

  " When editing a file, always jump to the last known cursor position.
  " Don't do it when the position is invalid or when inside an event handler
  " (happens when dropping a file on gvim).
  autocmd BufReadPost *
\ if line("'\"") >= 1 && line("'\"") <= line("$") |
\   exe 

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

James McCoy wrote:

> On Mon, Jul 25, 2016 at 07:39:55AM -0700, Ben Fritz wrote:
> > On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> > > 
> > >   if has("autocmd")
> > > " Enable file type detection.
> > > filetype plugin indent on
> > >   
> > 
> > Don't common plugin managers require you to turn on filetype stuff at
> > a very specific location, e.g. *after* loading the plugin manager
> > functionality?
> 
> By now, most of them do this automatically, but I still advocate against
> doing this before the vimrc is loaded since it causes non-obvious
> problems to users (and am annoyed that Ubuntu deviates from the way I've
> setup Debian's packaging in this regard).
> 
> The reason this needs to be done is to for ftdetect scripts.
> 
> Without doing the equivalent of
> 
>   :filetype off
>   " Setup plugin manager
>   " Re-run :filetype on, if needed
> 
> any ftdetect scripts located in the runtime paths handled by the plugin
> manager wouldn't have their settings applied.
> 
> Now, in Neovim we've enable filetype plugins and indent scripts by
> default.  However, we also track whether they were enabled
> automatically, or modified by the user, so that "filetype plugin on" in
> the user's vimrc only enables plugins instead of acting like a no-op.
> You can see the discussion of the behavior/implementation at
> .

Arent't users already executing the filetype command early in their
.vimrc?  If a plugin manager can't handle that, it has a problem anyway.
It has always been in the vimrc_example.vim.

We could postpone the effect of the :filetype command, but that will
most likely cause problems for users who intentionally do it early and
then overrule some of it.

I think plugins should not use ftdetect/*.vim but execute the
autocommands that it would contain in the plugin.  Is there any problem
with that?

-- 
Lose weight, NEVER Diet again with
  The "Invisible Weight Loss Patch"
(spam e-mail)

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Erik Falor]

On Mon, Jul 25, 2016 at 07:37:46AM -0700, Ben Fritz wrote:
> If one were to change anything for ease-of-use for new users, it wouldn't be 
> 'hidden', it would be 'confirm', so that Vim becomes consistent with many 
> other programs which don't just refuse to quit when you have unsaved changes, 
> they instead ask you whether you want to save first.

+1
This would remove a big stumbling block from new users, and would be
minimally invasive to old hands.

-- 
Erik Falor
Registered Linux User #445632http://unnovative.net

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: PGP signature

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Tony Mechelynck wrote:

> On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt  
> wrote:
> > Hi Bram!
> >
> > On So, 24 Jul 2016, Bram Moolenaar wrote:
> >
> >> > please no hlsearch. That is most often annoying.
> >>
> >> Well, I find it useful.  But I suppose that's more a personal
> >> preference.
> >
> > perhaps, if we made ctrl-l clear the search highlighting by default?
> >
> >> > some more I would set, the mentioned
> >> > :set display+=lastline
> >>
> >> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
> >> be surprised if this changes.
> >
> > Really? I think the default of a bunch of '@'
> > doesn't really help anybody, instead show at least the beginning of the
> > line.
> >
> 
> For people like me, who set 'wrap', display-=lastline would replace a
> "long last line" by several rows of @... which can be _extremely_
> annoying. Just @@@ at bottom right (or at bottom left if 'rightleft'
> is set) should IMHO be sufficient to show that the line goes on after
> the end of the screen, without filling maybe half the screen with only
> row after row after row of only at-signs.
> 
> Of course I set +=lastline myself, since I need it and ATM it is not a
> default, but I can't imagine someone hollering in dismay if a last
> line (of several screen lines if 'wrap' is set) weren't anymore filled
> with at-signs only, but only the last three character cells were.

The problem of the current "lastline" implementation is that the @@@ at
the end is quite hard to spot.  Switching from the old Vi behavior of
all "@" lines to that is quite a big jump:

old:
asdf asdf asdf asdf asd
@
@
@
@

lastline:
asdf asdf asdf asdf asd
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fas@@@

At the same time, the "@" lines filling most of the screen it useless.
I think everybody agrees with that.

So, trying to find a solution that we can use as default for everybody,
how about this: Show "@@@" in the last line, no other text.  Then it's
clear there is more following, but still showing the lines that are
available.  For a two-screen-line while there is only space for one, you
would only get "@@@".  Users who want more can switch to "lastline" as
before.  We could call this "truncate"

truncate:
asdf asdf asdf asdf asd
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
asdf asdf asdf asdf asd fasdf asdf asdf asd fasd f
@@@


-- 
ROBIN:  The what?
ARTHUR: The Holy Hand Grenade of Antioch.  'Tis one of the sacred relics
Brother Maynard always carries with him.
ALL:Yes. Of course.
ARTHUR: (shouting) Bring up the Holy Hand Grenade!
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Thomas Köhler]

Hi Bram,

On Sun, Jul 24, 2016 at 03:02:56PM +0200, Bram Moolenaar  
wrote:
> Vim has always been conservative about the default option values.

And that is actually a very good thing.

As I work as a consultant, and the systems the customers use have
a wide variety of Linux distributions of varying age and thus vim
default settings, most often I end up setting a few options
anyway.  (I often go with ":se ls=2 nu nocp" and "colorscheme
koehler" for a basic "feel at home" setting, while my .vimrc at
home is rather long (~800 lines)).

I'd like to share some thoughts here.

> What we can probably always do:
> 
>   set backspace=indent,eol,start

I personally don't like that one, especially the "start" part of
it. I always considered it a feature to not be able to backspace
over the start of insert.
Actually, when I encounter a vim that is configured to add
"start" to 'backspace', I usually unset this as soon as I see it.

>   set history=50  " keep 50 lines of command line history
>   set ruler   " show the cursor position all the time
>   set showcmd " display incomplete commands
>   set incsearch   " do incremental searching

I often use all of those, also adding hlsearch.

>   " Don't use Ex mode, use Q for formatting
>   map Q gq

I don't like this one. But then I occassionally actually use Ex mode.

>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif

Please... no.
I always hat it whenever a distribution does this by default,
moving the cursor for a simple cut operation.

>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif

I could live with those (usually using most of that anyway, not
the c_comment_strings however)

>   if has("autocmd")
[...]
>   endif

I'd suggest not using that.

>   if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif

I don't actually care about this one.

> Probably not:
> 
>   " these two leave files behind
>   set backup
>   set undofile
> 
>   " may conflict with a user mapping
>   inoremap  u
> 
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif

Yes, please leave those out.


Ciao,
Thomas

-- 
 Thomas Köhler   Email:   jean-...@picard.franken.de
 <>< WWW:  http://gott-gehabt.de
 IRC: tkoehler   Freenode: thkoehler
 PGP public key available from Homepage!

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-26, Tony Mechelynck wrote:
> On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall
>  wrote:
> > On Monday, July 25, 2016 at 3:11:11 PM UTC-5, Christian Brabandt wrote:
> >> Hi Bram!
> >>
> >> On So, 24 Jul 2016, Bram Moolenaar wrote:
> >>
> >> > > please no hlsearch. That is most often annoying.
> >> >
> >> > Well, I find it useful.  But I suppose that's more a personal
> >> > preference.
> >>
> >> perhaps, if we made ctrl-l clear the search highlighting by default?
> >
> > I personally like the idea of turning on hlsearch by default, but +1 to
> > the idea of also making ctrl-l clear the hl.
> >
> > ~Tumbler Terrall
> >
> 
> 'incsearch' and 'hlsearch' are part of the settings set by the
> vimrc_example.vim, and I like them. Clearing the highlight whenever I
> repaint the screen? Hm, I'm not convinced. I dont like the idea of
> having Ctrl-L serve as both ":redraw" and ":nohls" which are totally
> unrelated in my mind. I prefer the latest search highlight to remain
> highlighted regardless of possible screen repaints, until or unless I
> explicitly turn it off with either ":nohls" or ":let @/ = ''" (i.e.,
> in case your email reader doesn't clearly display quotation marks,
> make the search register an empty string).

The only time I use Ctrl-L is when something has messed up my
display and I want to redraw it.  I just want it redrawn exactly as
it was, including any search highlights.  If you want to have Ctrl-L
also execute :nohls, create a mapping.

Regards,
Gary

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 10:00 PM, Bram Moolenaar  wrote:
>
> Hirohito Higashi wrote:
>
>> I think it is better to change the default value of Vim body for some
>> of the options.
>>
>> i.e.
>> set wildmenu
>> set ruler
>> set showcmd
>> set tags=./tags;,tags;
>> etc...
>>
>> Obviously useful things should be changed.
>
> A few people have mentioned setting 'wildmenu'.  I also have that set.
> I wonder if there are real disadvantages to setting it by default?
>
> Keep in mind that most of these defaults are for options that new users
> would not even know about.  It's possible that a few users don't like it
> and have to disable it in their .vimrc.  So long as that number is
> small (less than 1%?) that would be an acceptable price for helping new
> users enjoying Vim more.
>

I use 'wildmenu' too, but it should be remembered that it goes hand in
hand with 'wildmode' and for the latter I'm not sure everyone, or even
most people, use the same setting (I use ":set
wildmode=longest:full,full".)

Otherwise I like it so much that I source menu.vim in my vimrc
(guarded of course by "if has('menu') && !has('gui_running')") in
order to be able to use the gvim-like menus (File, Edit, etc.) even in
Console mode, on the statusline (and even though I actually don't use
them often).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tumbler Terrall]

On Monday, July 25, 2016 at 3:11:11 PM UTC-5, Christian Brabandt wrote:
> Hi Bram!
> 
> On So, 24 Jul 2016, Bram Moolenaar wrote:
> 
> > > please no hlsearch. That is most often annoying.
> > 
> > Well, I find it useful.  But I suppose that's more a personal
> > preference.
> 
> perhaps, if we made ctrl-l clear the search highlighting by default?

I personally like the idea of turning on hlsearch by default, but +1 to
the idea of also making ctrl-l clear the hl. 

~Tumbler Terrall

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[James McCoy]

On Mon, Jul 25, 2016 at 07:39:55AM -0700, Ben Fritz wrote:
> On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> > 
> >   if has("autocmd")
> > " Enable file type detection.
> > filetype plugin indent on
> >   
> 
> Don't common plugin managers require you to turn on filetype stuff at
> a very specific location, e.g. *after* loading the plugin manager
> functionality?

By now, most of them do this automatically, but I still advocate against
doing this before the vimrc is loaded since it causes non-obvious
problems to users (and am annoyed that Ubuntu deviates from the way I've
setup Debian's packaging in this regard).

The reason this needs to be done is to for ftdetect scripts.

Without doing the equivalent of

  :filetype off
  " Setup plugin manager
  " Re-run :filetype on, if needed

any ftdetect scripts located in the runtime paths handled by the plugin
manager wouldn't have their settings applied.

Now, in Neovim we've enable filetype plugins and indent scripts by
default.  However, we also track whether they were enabled
automatically, or modified by the user, so that "filetype plugin on" in
the user's vimrc only enables plugins instead of acting like a no-op.
You can see the discussion of the behavior/implementation at
.

Cheers,
-- 
James
GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7  2D23 DFE6 91AE 331B A3DB

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Tue, Jul 26, 2016 at 12:10 AM, Tumbler Terrall
 wrote:
> On Monday, July 25, 2016 at 3:11:11 PM UTC-5, Christian Brabandt wrote:
>> Hi Bram!
>>
>> On So, 24 Jul 2016, Bram Moolenaar wrote:
>>
>> > > please no hlsearch. That is most often annoying.
>> >
>> > Well, I find it useful.  But I suppose that's more a personal
>> > preference.
>>
>> perhaps, if we made ctrl-l clear the search highlighting by default?
>
> I personally like the idea of turning on hlsearch by default, but +1 to
> the idea of also making ctrl-l clear the hl.
>
> ~Tumbler Terrall
>

'incsearch' and 'hlsearch' are part of the settings set by the
vimrc_example.vim, and I like them. Clearing the highlight whenever I
repaint the screen? Hm, I'm not convinced. I dont like the idea of
having Ctrl-L serve as both ":redraw" and ":nohls" which are totally
unrelated in my mind. I prefer the latest search highlight to remain
highlighted regardless of possible screen repaints, until or unless I
explicitly turn it off with either ":nohls" or ":let @/ = ''" (i.e.,
in case your email reader doesn't clearly display quotation marks,
make the search register an empty string).

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 10:10 PM, Christian Brabandt  wrote:
> Hi Bram!
>
> On So, 24 Jul 2016, Bram Moolenaar wrote:
>
>> > please no hlsearch. That is most often annoying.
>>
>> Well, I find it useful.  But I suppose that's more a personal
>> preference.
>
> perhaps, if we made ctrl-l clear the search highlighting by default?
>
>> > some more I would set, the mentioned
>> > :set display+=lastline
>>
>> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
>> be surprised if this changes.
>
> Really? I think the default of a bunch of '@'
> doesn't really help anybody, instead show at least the beginning of the
> line.
>

For people like me, who set 'wrap', display-=lastline would replace a
"long last line" by several rows of @... which can be _extremely_
annoying. Just @@@ at bottom right (or at bottom left if 'rightleft'
is set) should IMHO be sufficient to show that the line goes on after
the end of the screen, without filling maybe half the screen with only
row after row after row of only at-signs.

Of course I set +=lastline myself, since I need it and ATM it is not a
default, but I can't imagine someone hollering in dismay if a last
line (of several screen lines if 'wrap' is set) weren't anymore filled
with at-signs only, but only the last three character cells were.

> Just my opinion however,
>
>
> Best,
> Christian

And just mine.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Mon, Jul 25, 2016 at 4:00 PM, Bram Moolenaar  wrote:

>
> Hirohito Higashi wrote:
>
> > I think it is better to change the default value of Vim body for some
> > of the options.
> >
> > i.e.
> > set wildmenu
> > set ruler
> > set showcmd
> > set tags=./tags;,tags;
> > etc...
> >
> > Obviously useful things should be changed.
>
> A few people have mentioned setting 'wildmenu'.  I also have that set.
> I wonder if there are real disadvantages to setting it by default?
>

What are the advantages to *setting* it?  This looks like a shining example
of "personal preference".

Keep in mind that most of these defaults are for options that new users
> would not even know about.  It's possible that a few users don't like it
> and have to disable it in their .vimrc.  So long as that number is
> small (less than 1%?) that would be an acceptable price for helping new
> users enjoying Vim more.
>

Much of what is in the proposal works contrary to that purpose.

> Keep in mind that most of these defaults are for options that new users
> would not even know about.

This also means some of them are going to be unexpected, even jarring, to
new users.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Charles E Campbell]

Christian Brabandt wrote:
> Hi Bram!
>
> On So, 24 Jul 2016, Bram Moolenaar wrote:
>
>>> please no hlsearch. That is most often annoying.
>> Well, I find it useful.  But I suppose that's more a personal
>> preference.
> perhaps, if we made ctrl-l clear the search highlighting by default?
>
>>> some more I would set, the mentioned
>>> :set display+=lastline
>> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
>> be surprised if this changes.
> Really? I think the default of a bunch of '@'
> doesn't really help anybody, instead show at least the beginning of the 
> line.
>
> Just my opinion however,
>
How about another opinion? :)

I use ve=all and nowrap, not that I think these should be inflicted on
everyone.  However, because of the nowrap, I don't really need the
display+=lastline as I don't get those @s.  So I don't suppose I would
be affected either way.

Regards,
Chip

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Christian Brabandt]

Hi Bram!

On So, 24 Jul 2016, Bram Moolenaar wrote:

> > please no hlsearch. That is most often annoying.
> 
> Well, I find it useful.  But I suppose that's more a personal
> preference.

perhaps, if we made ctrl-l clear the search highlighting by default?

> > some more I would set, the mentioned
> > :set display+=lastline
> 
> As mentioned, I don't use it myself, I expect long time Vi/Vim users to
> be surprised if this changes.

Really? I think the default of a bunch of '@'
doesn't really help anybody, instead show at least the beginning of the 
line.

Just my opinion however,


Best,
Christian
-- 
Gemeinsame Erinnerungen sind manchmal die besten Friedensstifter.
-- Marcel Proust

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 8:03 PM, Charles E Campbell
 wrote:
+>> set langnoremap
>>   endif
>
> I had to look this one up as I've never had cause to use it.  Easily
> reversed, so I'm neutral on this one.
>>
>>
>> Probably not:
>>
>>   " these two leave files behind
>>   set backup
>>   set undofile
>>
>>   " may conflict with a user mapping
>>   inoremap  u
>>
>>   " hard to revert
>>   if has('syntax') && has('eval')
>> packadd matchit
>>   endif
>>
>> Comments?
>>
> Leaving files behind -- I have enough of a problem with macs and .dSYM
> directories getting into my tarballs; I use set directory to move swap
> files where I don't back them up, and I've not used undofiles.  These
> two are easily reversible, though.  I'm sure I wouldn't like the
> proposed ctrl-u map, although I know how to get rid of it so it wouldn't
> be a major problem.  I think it would be best to document any of these
> changes and include how-to-prevent/restore/obviate them.  Does the last
> item (with matchit) mean that matchit will become a package which must
> be packadd'd?
>
> Regards,
> Chip Campbell
>

Actually, matchit is already now a package which the current
vimrc_example.vim packadds. Easier to do than the former
jumping-through-hoops to get it from the "macros" directory where it
used to be distributed. The files in /macros/ are still there, though
the macros/matchit.vim now sources the appropriate matchit.vim script
in the packages directory. If you included a copy or a symlink of
macros/matchit.txt in the doc subdirectory of one of your
'runtimepath' folders, and also source whatever is at any time the
latest vimrc_example.vim, you'll notice that matchit.txt is now listed
twice among the "user additions" near the end of
$VIMRUNTIME/doc/help.txt when invoked from within Vim. Similarly, if
you included the matchit.vim plugin "the old way" and also source the
vimrc_example.vim, ":scriptnames" now also lists matchit twice but it
is a little harder to spot.

Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Charles E Campbell]

Bram Moolenaar wrote:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
>   set backspace=indent,eol,start
>   set history=50  " keep 50 lines of command line history
>   set ruler   " show the cursor position all the time
>   set showcmd " display incomplete commands
>   set incsearch   " do incremental searching

Except for incsearch, my .vimrc already incorporates these settings, so
I'm fine with them myself.  incsearch is "noisy" and changes the visual
interface (ie. becomes prominent) and I don't advise doing so, even
though I myself might decide to use it someday.  At least its easily
reversible in one's .vimrc.
>
>   " Don't use Ex mode, use Q for formatting
>   map Q gq

Doesn't modify look (unless one types a "Q", of course).  Guess I'm
neutral on this one.
>
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif

Probably a good idea.
>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif

Setting hlsearch definitely modifies the look, and I myself only
use hls in specific situations.  I'd rather not have this one, although
at least its easy to countermand with a set nohls.
>
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>   
> augroup vimrcEx
> au!
>   
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
This modifies look and is difficult to prevent except on a
file-by-file basis.  Please don't do this.
>   
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif
I myself already do something like this in my  .vimrc.  However, even
though I like this, it would be difficult not-to-have.  Perhaps cp
should have levels: 0=compatible, 1= current nocp, 2=more, etc, or
perhaps a letter-driven selection (something like complete).
>   
> augroup END
>   else
> set autoindent" always set autoindenting on
>   endif
I don't care, I guess -- easily reversed.
>   
>   if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif

I had to look this one up as I've never had cause to use it.  Easily
reversed, so I'm neutral on this one.
>
>
> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile
>
>   " may conflict with a user mapping
>   inoremap  u
>
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif
>
> Comments?
>
Leaving files behind -- I have enough of a problem with macs and .dSYM
directories getting into my tarballs; I use set directory to move swap
files where I don't back them up, and I've not used undofiles.  These
two are easily reversible, though.  I'm sure I wouldn't like the
proposed ctrl-u map, although I know how to get rid of it so it wouldn't
be a major problem.  I think it would be best to document any of these
changes and include how-to-prevent/restore/obviate them.  Does the last
item (with matchit) mean that matchit will become a package which must
be packadd'd?

Regards,
Chip Campbell

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because 

Re: Changing the defaults with Vim 8

[h_east]

Hi Bram and All,

I think it is better to change the default value of Vim body for some of the 
options.

i.e.
set wildmenu
set ruler
set showcmd
set tags=./tags;,tags;
etc...

Obviously useful things should be changed.

Thanks.
--
Best regards,
Hirohito Higashi (a.k.a. h_east)

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Ben Fritz]

On Sunday, July 24, 2016 at 8:03:06 AM UTC-5, Bram Moolenaar wrote:
> 
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>   

Don't common plugin managers require you to turn on filetype stuff at a very 
specific location, e.g. *after* loading the plugin manager functionality?

I.e. will this interfere with plugin managers? Or is it enough for them to 
document "filetype off...enableMe()...filetype plugin indent on" in their 
installation instructions?

I guess many Vim distributions already enable filetype stuff in the system 
vimrc, so maybe the installation instructions already account for this.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Ben Fritz]

On Monday, July 25, 2016 at 8:02:21 AM UTC-5, Tony Mechelynck wrote:
> On Mon, Jul 25, 2016 at 11:00 AM,   wrote:
> > Ideally, starting the program as 'vim' would automatically give the user 
> > the improvements promised in the name. And 'vi' would hide all those 
> > improvements.
> >
> > Here is my list of options to set when run as 'vim':
> [...]
> > set hidden
> >
> > Because 'nohidden' is too inflexible and 'hidden' would prevent new users 
> > from using tab pages as file proxies.
> [...]
> 
> I disagree.
> When I :quit a file, or otherwise |abandon| it, I want it to be quit,
> not to remain there in-memory-but-not-saved. I use 'autowriteall' to
> save it _to disk_ if possible, but I don't pretend that everyone will
> want that setting. And if I want my changes to be lost (which happens,
> but rarely) I explicitly use :q! instead of :q when quitting the file.
> 
> If _you_ want to use 'hidden', then set it in your vimrc, but don't
> force every people who don't want it to explicitly ":set nohidden" in
> _their_ vimrc. 

I agree with Tony, 'hidden' is not actually very friendly to new users.

And, I don't see how it's going to prevent anyone from using tab pages as file 
proxies.

If one were to change anything for ease-of-use for new users, it wouldn't be 
'hidden', it would be 'confirm', so that Vim becomes consistent with many other 
programs which don't just refuse to quit when you have unsaved changes, they 
instead ask you whether you want to save first.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Nelo-Thara Wallus]

On 2016-07-24 15:02, Bram Moolenaar wrote:
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78

I'd object to that, autocommands are executed after ftplugins and would
overwrite user settings (unless the user creates an au to change it).

So a user who wants a different textwidth would have to riddle the vimrc
with autocommands or place them in a plugin/ file.

> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile

These two would be handy by default, imho, but with the addition of
a new default for  and :

set backupdir=~/tmp,~/.vim/backup,/tmp/vim-backup
set undodir=~/tmp,~/.vim/undo,/tmp/vim-undo

Or similar - as long as it doesn't include the pwd by default anymore,
since that is causing a lot of confusion with new users.

The same would be nice for the default , which also puts the
swapfiles into the pwd instead of somewhere where it doesn't annoy the
user.

--
Viktoriastrasse 22
76133 Karlsruhe
Nr.:0721 / 96 55 63 95
Mobile:  0178 / 53 17 067
Web:https://nelo.wallus.de/
/"\  ASCII Ribbon Campaign
\ /  - against HTML emails
 X   - against proprietory attachments
/ \  http://en.wikipedia.org/wiki/ASCII_Ribbon_Campaign

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Tony Mechelynck]

On Mon, Jul 25, 2016 at 11:00 AM,   wrote:
> Ideally, starting the program as 'vim' would automatically give the user the 
> improvements promised in the name. And 'vi' would hide all those improvements.
>
> Here is my list of options to set when run as 'vim':
[...]
> set hidden
>
> Because 'nohidden' is too inflexible and 'hidden' would prevent new users 
> from using tab pages as file proxies.
[...]

I disagree.
When I :quit a file, or otherwise |abandon| it, I want it to be quit,
not to remain there in-memory-but-not-saved. I use 'autowriteall' to
save it _to disk_ if possible, but I don't pretend that everyone will
want that setting. And if I want my changes to be lost (which happens,
but rarely) I explicitly use :q! instead of :q when quitting the file.

If _you_ want to use 'hidden', then set it in your vimrc, but don't
force every people who don't want it to explicitly ":set nohidden" in
_their_ vimrc. When I first became a serious Vim user, I went through
all the options and added vimrc lines for those where I wanted a
nondefault value (or to be precise, a different value than what the
vimrc_example.vim sets, since it sets most, but not all, of my
preferred settings and I source it in my vimrc); I definitely did not
add :set lines for _all_ of those whose defaults where the values I
preferred; reading your post makes me thing maybe I should have after
all.


Best regards,
Tony.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Gary Johnson]

On 2016-07-24, Bram Moolenaar wrote:
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> 
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
> 
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
> 
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
> 
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
> 
> What we can probably always do:

[...]

> Comments?

I think that for all the reasons you have given over the years,
changing the default behavior or default option values is a bad
idea.

I'm not sure what problem you're trying to solve.

Experienced users of Vim have already tweaked their vimrc files with
their preferred settings.  Changing the defaults is not going to
help them.

The Windows installer already creates a default system _vimrc in
$VIM which is used until a user creates their own ~/_vimrc.  The
system _vimrc could be changed to use whatever options values you
think would be better.  New users will get the new option values.
Existing users will keep their existing option values.

Linux users usually start with the Vim package for their
distribution.  Fedora-derived distributions and Ubuntu-derived
distributions at least provide system vimrc files with the option
values those package maintainers think are best.  So those users
already get "better" initial option values.

Many Linux users build their own Vim.  These users are usually
experienced enough to have a vimrc that sets their preferred option
values.  For those users that are not so experienced, you could
change "make install" to look for ~/.vim/vimrc, and if it doesn't
already exist, create one that has your idea of better initial
settings.

I understand that Vim could be made more useful and appealing to new
users with different default settings, but putting those settings in
a configuration file (such as $VIM/_vimrc on Windows or $VIM/vimrc
on Unix if not already present) could solve that problem without
changing the actual default settings or breaking existing users'
expectations or configurations.

Regards,
Gary

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Ingo Karkat]

Manuel Ortega  wrote:
> On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar  wrote:
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78
> Please don't "setlocal" a  value for text files.  Don't mess
> with this at all, but if you do, don't make it "setlocal".  It is
> extremely annoying to have Vim sometimes hard-wrap lines and sometimes
> not, depending on which kind of file you're in---unless one specifically
> authorized this by purposely turning filetype plugins on or having a
> plugin/package that does this for certain 

Using :autocmd FileType sets a bad precedent: this doesn't scale (one
autocmd per filetype and setting is too much and bloats the .vimrc), and
Vim has a much better mechanism for filetype-specific settings:
ftplugins (with :filetype plugin on). This way, the change is also
undone (through b:undo_ftplugin), if the user manually changes the
filetype.

With regards to the 'textwidth' setting: I would recommend to leave this
out, as there's no generally accepted notion of a "text" file;
hard-wrapping may be desired or not, so it's best to leave this up to
the user.

-- regards, ingo

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: OpenPGP digital signature

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Christian Brabandt wrote:

> >   set backspace=indent,eol,start
> 
> +1
> 
> >   set history=50" keep 50 lines of command line history
> 
> Why only 50?

Good point, the Vim default already is 50.  That changed a while back.
How about 200?

> And while we are it, increase the undolevels setting

The default already is 1000.  A higher value is mainly useful in
combination with 'undofile', but we don't want to set that.

> >   set ruler " show the cursor position all the time
> >   set showcmd   " display incomplete commands
> >   set incsearch " do incremental searching
> >   " Don't use Ex mode, use Q for formatting
> >   map Q gq
> > 
> >   " In many terminal emulators the mouse works just fine, thus enable it.
> >   if has('mouse')
> > set mouse=a
> >   endif
> 
> don't care.
> 
> >   if _Co > 2 || has("gui_running")
> > syntax on
> > set hlsearch
> 
> please no hlsearch. That is most often annoying.

Well, I find it useful.  But I suppose that's more a personal
preference.

> >   if has("autocmd")
> > " Enable file type detection.
> > filetype plugin indent on
> 
> +1
> 
> >   
> > augroup vimrcEx
> > au!
> >   
> > " For all text files set 'textwidth' to 78 characters.
> > autocmd FileType text setlocal textwidth=78
> 
> Isn't text a fallback, that is used, when no other type is found? I 
> wouldn't set this one then.

No, but it can trigger quite often.  I suppose this is too arbitrary.

> 
> > " When editing a file, always jump to the last known cursor position.
> > " Don't do it when the position is invalid or when inside an event 
> > handler
> > " (happens when dropping a file on gvim).
> > autocmd BufReadPost *
> >   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
> >   \   exe "normal! g`\"" |
> >   \ endif
> 
> +1 
> 
> > Probably not:
> > 
> >   " these two leave files behind
> >   set backup
> >   set undofile
> > 
> >   " may conflict with a user mapping
> >   inoremap  u
> > 
> >   " hard to revert
> >   if has('syntax') && has('eval')
> > packadd matchit
> >   endif
> 
> +1 for not setting those. although I would still make  in insert 
> mode undoable.

OK.

> some more I would set, the mentioned
> :set display+=lastline

As mentioned, I don't use it myself, I expect long time Vi/Vim users to
be surprised if this changes.

> :set nrformat-=octal (often does unexpected things, when the user does 
> not expect it)

OK.

> and possibly also:
> :set laststatus=2

That takes an extra line from the screen.  I suppose it's useful if you
have a plugin for a super status line.

-- 
The Law of VIM:
For each member b of the possible behaviour space B of program P, there exists
a finite time t before which at least one user u in the total user space U of
program P will request b becomes a member of the allowed behaviour space B'
(B' <= B).
In other words: Sooner or later everyone wants everything as an option.
-- Vince Negri

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Tyru wrote:

> so do you think this setting is also personal preference, not 'compatible'
> one?
> 
> set display+=lastline
> 
> Any reason to not display long line instead of '@' ?
> for speed?
> is it really good default value for "normal user" ?

I'm not sure if I am a good example, but I don't use that.  I don't
often have text with long lines and it's nice to easily see the last
line is incomplete.  It's one of those things that make the editor feel
like Vi.

-- 
My girlfriend told me I should be more affectionate.
So I got TWO girlfriends.

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Christian Brabandt]

>   set backspace=indent,eol,start

+1

>   set history=50  " keep 50 lines of command line history

Why only 50?

And while we are it, increase the undolevels setting


>   set ruler   " show the cursor position all the time
>   set showcmd " display incomplete commands
>   set incsearch   " do incremental searching
>   " Don't use Ex mode, use Q for formatting
>   map Q gq
> 
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif

don't care.

>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch

please no hlsearch. That is most often annoying.

>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on

+1

>   
> augroup vimrcEx
> au!
>   
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78

Isn't text a fallback, that is used, when no other type is found? I 
wouldn't set this one then.

> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif

+1 

> Probably not:
> 
>   " these two leave files behind
>   set backup
>   set undofile
> 
>   " may conflict with a user mapping
>   inoremap  u
> 
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif

+1 for not setting those. although I would still make  in insert 
mode undoable.

some more I would set, the mentioned
:set display+=lastline
:set nrformat-=octal (often does unexpected things, when the user does 
not expect it)

and possibly also:
:set laststatus=2

Best,
Christian
-- 
Charade

Das Erste, das ist immer,
Und wenn auch die Welt vergeht;
Das Zweite ist man und bleibt man,
Wenn man zu lesen versteht.

-- Heinrich Heine

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[tyru]

Hi Bram,

2016/07/25 0:33 "Bram Moolenaar" :
>
>
> Nicola wrote:
>
> > On 2016-07-24 13:02:56 +, Bram Moolenaar said:
> >
> > > Vim has always been conservative about the default option values.
> > > Without any .vimrc the default is 'compatible'.  That's nice for
people
> > > who rely on the old Vi.  But how many of these still exist?  I expect
> > > nearly all Vim users to want 'nocompatible', thus create a .vimrc
ASAP.
> > >
> > > What has stopped me from changing this is the unexpected change.  Many
> > > users will notice that Vim suddenly behaves differently.  Some may be
> > > upset.  The release of Vim 8.0 might be the best point in time to do
> > > this.  If we do this.
> >
> > Talking as someone who has been using Vim only for a couple of years and
> > who does not work with systems more than a decade old, I would welcome
> > such changes. And a major release obviously provides the best
opportunity
> > for introducing backward-incompatible changes.
> >
> > I agree with the defaults you are proposing. How about the following?
> >
> > 1) nnoremap Y y$
>
> Please, this was not an invitation for everybody to mention their
> favorite adjustments.

Sorry, it's too much.

so do you think this setting is also personal preference, not 'compatible'
one?

set display+=lastline

Any reason to not display long line instead of '@' ?
for speed?
is it really good default value for "normal user" ?

> In this case it's clear that most people,
> including myself, expect Y to yank the current line.  Changing this is
> clearly a personal preference, not something that will help all users.
>
> > 2) Make UTF8 the default encoding.
>
> That is something that could break things in weird ways.  Vim already
> automatically sets 'encoding' to utf-8 in situations where it makes
> sense.
>
> > > What we can probably always do:
> > >
> > >   " In many terminal emulators the mouse works just fine, thus enable
it.
> > >   if has('mouse')
> > > set mouse=a
> > >   endif
> >
> > I would also set ttymouse=sgr when possible (but I do not know all the
> > implications).
>
> This already happens when the required xterm version is detected.
>
> --
>[Autumn changed into Winter ... Winter changed into Spring ...
Spring
>changed back into Autumn and Autumn gave Winter and Spring a miss
and
>went straight on into Summer ...  Until one day ...]
>  "Monty Python and the Holy Grail" PYTHON (MONTY)
PICTURES LTD
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net
 \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/
\\\
> \\\  an exciting new programming language -- http://www.Zimbu.org
///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org
///
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups
"vim_dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
email to vim_dev+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Sun, Jul 24, 2016 at 12:09 PM, Manuel Ortega 
wrote:

> On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar 
> wrote:
>
>>
>>
>> Probably not:
>>
>>   " these two leave files behind
>>   set backup
>>   set undofile
>>
>>   " may conflict with a user mapping
>>   inoremap  u
>>
>>   " hard to revert
>>   if has('syntax') && has('eval')
>> packadd matchit
>>   endif
>>
>> Comments?
>>
>
>
> Definitely not!  Especially "matchit", since it's hard to reverse.  I
> don't want that thing.   will leave unexpected litter around,
> which is ban enough; but since the litter will start with dots it will
> unintentionally wind up making it into tarballs because people will forget
> that such files are lurking.  Also, the "backup" related things will mess
> up "creation date" in mac OS depending on how they're configured.
> Currently the creation date is preserved on macOS by Vim's default settings.
>

Scratch what I said about creation-date on macOS.  By default that isn't
preserved.  (I mistakenly thought it was because setting  will preserve
it, and the docs for  say that it is on by default for "unix".
Apparently OS X doesn't count as "unix", because on OS X  is set to
"auto".  Probably the docs should be corrected here.)

But add that setting  will leave litter around on the filesystem.
Please don't leave unexpected litter around on the filesystem.   Among
other things, such backup files are bound to unintentionally get captured
in tarballs.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Manuel Ortega]

On Sun, Jul 24, 2016 at 9:02 AM, Bram Moolenaar  wrote:

>
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
>   set backspace=indent,eol,start
>   set history=50" keep 50 lines of command line history
>   set ruler " show the cursor position all the time
>   set showcmd   " display incomplete commands
>   set incsearch " do incremental searching
>

Please do not set   It's one of the more annoying things in all
of Vim, and very likely to bring an unexpected "what the heck?"

  " Don't use Ex mode, use Q for formatting
>   map Q gq
>
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif
>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif
>
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>
> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event
> handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif
>
> augroup END
>   else
> set autoindent  " always set autoindenting on
>   endif
>

I am very opposed to everything in the above augroup.  There is no reason
to foist this stuff on people just because "7" is changing to "8".   Also
that BufReadPost autocmd is not easily reversible for newbs, since it's not
a simple "set".

Please don't "setlocal" a  value for text files.  Don't mess with
this at all, but if you do, don't make it "setlocal".  It is extremely
annoying to have Vim sometimes hard-wrap lines and sometimes not, depending
on which kind of file you're in---unless one specifically authorized this
by purposely turning filetype plugins on or having a plugin/package that
does this for certain 

  if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif
>
>
> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile
>
>   " may conflict with a user mapping
>   inoremap  u
>
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif
>
> Comments?
>


Definitely not!  Especially "matchit", since it's hard to reverse.  I don't
want that thing.   will leave unexpected litter around, which is
ban enough; but since the litter will start with dots it will
unintentionally wind up making it into tarballs because people will forget
that such files are lurking.  Also, the "backup" related things will mess
up "creation date" in mac OS depending on how they're configured.
Currently the creation date is preserved on macOS by Vim's default settings.

I'm not in general opposed automatically to the idea of making a small
tweak or two for Vim 8, provided they won't affect too many people.  E.g.,
 is probably OK.   But this proposal has too many of them, and
for no good reason.  Frankly, for no reason at all other than "they happen
to appear in an example of a vimrc".  Probably all that should happen is
that  is the default.  Definitely add nothing that requires
more than  a simple "set" cmd to reverse, and nothing that affects the
filesystem.

-Manny

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit 

Re: Changing the defaults with Vim 8

[Bram Moolenaar]

Nicola wrote:

> On 2016-07-24 13:02:56 +, Bram Moolenaar said:
> 
> > Vim has always been conservative about the default option values.
> > Without any .vimrc the default is 'compatible'.  That's nice for people
> > who rely on the old Vi.  But how many of these still exist?  I expect
> > nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> > 
> > What has stopped me from changing this is the unexpected change.  Many
> > users will notice that Vim suddenly behaves differently.  Some may be
> > upset.  The release of Vim 8.0 might be the best point in time to do
> > this.  If we do this.
> 
> Talking as someone who has been using Vim only for a couple of years and
> who does not work with systems more than a decade old, I would welcome
> such changes. And a major release obviously provides the best opportunity
> for introducing backward-incompatible changes.
> 
> I agree with the defaults you are proposing. How about the following?
> 
> 1) nnoremap Y y$

Please, this was not an invitation for everybody to mention their
favorite adjustments.  In this case it's clear that most people,
including myself, expect Y to yank the current line.  Changing this is
clearly a personal preference, not something that will help all users.

> 2) Make UTF8 the default encoding.

That is something that could break things in weird ways.  Vim already
automatically sets 'encoding' to utf-8 in situations where it makes
sense.

> > What we can probably always do:
> > 
> >   " In many terminal emulators the mouse works just fine, thus enable it.
> >   if has('mouse')
> > set mouse=a
> >   endif
> 
> I would also set ttymouse=sgr when possible (but I do not know all the 
> implications).

This already happens when the required xterm version is detected.

-- 
   [Autumn changed into Winter ... Winter changed into Spring ...  Spring
   changed back into Autumn and Autumn gave Winter and Spring a miss and
   went straight on into Summer ...  Until one day ...]
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Michal Grochmal]

Hi Bram,

> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
> 
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.

I will argue that *almost all* Linux user will not see the change.  Once
upon a time I had an issue with nocp on my Arch Linux.  It turns out
that Arch does `set nocompatible' inside /etc/vimrc that comes with its
packages.

I have also tested on a modern Debian (Jessie) and a modern CentOS (7),
and both also perform `set nocompatible' inside the distributed Vim.

The only package that I found that sets `compatible' was Debian's
`vim-tiny'.  But even then, the package explicitly does `set compatible'
inside `/etc/vimrc'.  Therefore not even the users of that distribution
of Vim will notice.

(Compiling from source is another story, of course)

-- 
Mike Grochmal
key ID 0xC840C4F6

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Yegappan Lakshmanan]

Hi,

On Sun, Jul 24, 2016 at 7:04 AM, lilydjwg  wrote:
> Hi,
>
> On Sun, Jul 24, 2016 at 10:21:32PM +0900, tyru wrote:
>> I want to propose the following settings additionally.
>>
>> 
>> set ambiwidth=double
>
> Please don't do this for Linux terminals, at least when it doesn't work
> well:
>

I agree.  This option should not be set to 'double' by default in the system
wide vimrc. I also ran into xterm screen refresh problems with this option.
I have set 'ambiwidth' to 'single' in .vimrc to avoid this problem.

- Yegappan

>
> For the following text,
>
> “test”
> ‘test’
>
> gvim works well:
> https://img.vim-cn.com/cb/1ef8cb00cb23be45a49ae2764a7c1531fb3cc0.png
>
> But my terminal has some issue with the placement and highlighting:
> https://img.vim-cn.com/92/c802187c35e82857c7c96311f9198b71a35a5c.png
>
> The left quotes are placed too left, and the right half doesn't get
> highlighted as expected.
>
> When I delete the first t's, the display is wrong:
> https://img.vim-cn.com/42/c990d919df4c568f1105063112d0569a7107da.png
>
> This happens to me with both xterm and xfce4-terminal on Arch Linux.
>
> Versions:
>
> * xterm 325
> * xfce4-terminal 0.6.3
> * gvim 7.4.2098
>
> It displays better with xterm -cjk_width, but there are still some issues:
> https://img.vim-cn.com/d6/07e66736903fb6bb55c687237f94637765a77b.png
>
>> set display=lastline
>> set formatoptions+=j
>> set nrformats-=octal
>> [...]
>
> --
> Best regards,
> lilydjwg
>

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[lilydjwg]

Hi,

On Sun, Jul 24, 2016 at 10:21:32PM +0900, tyru wrote:
> I want to propose the following settings additionally.
> 
> 
> set ambiwidth=double

Please don't do this for Linux terminals, at least when it doesn't work
well:

For the following text,

“test”
‘test’

gvim works well:
https://img.vim-cn.com/cb/1ef8cb00cb23be45a49ae2764a7c1531fb3cc0.png

But my terminal has some issue with the placement and highlighting:
https://img.vim-cn.com/92/c802187c35e82857c7c96311f9198b71a35a5c.png

The left quotes are placed too left, and the right half doesn't get
highlighted as expected.

When I delete the first t's, the display is wrong:
https://img.vim-cn.com/42/c990d919df4c568f1105063112d0569a7107da.png

This happens to me with both xterm and xfce4-terminal on Arch Linux.

Versions:

* xterm 325
* xfce4-terminal 0.6.3
* gvim 7.4.2098

It displays better with xterm -cjk_width, but there are still some issues:
https://img.vim-cn.com/d6/07e66736903fb6bb55c687237f94637765a77b.png

> set display=lastline
> set formatoptions+=j
> set nrformats-=octal
> [...]

-- 
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
-- 
A: Because it obfuscates the reading.
Q: Why is top posting so bad?

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[Nicola]

On 2016-07-24 13:02:56 +, Bram Moolenaar said:


Vim has always been conservative about the default option values.
Without any .vimrc the default is 'compatible'.  That's nice for people
who rely on the old Vi.  But how many of these still exist?  I expect
nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.

What has stopped me from changing this is the unexpected change.  Many
users will notice that Vim suddenly behaves differently.  Some may be
upset.  The release of Vim 8.0 might be the best point in time to do
this.  If we do this.


Talking as someone who has been using Vim only for a couple of years and
who does not work with systems more than a decade old, I would welcome
such changes. And a major release obviously provides the best opportunity
for introducing backward-incompatible changes.

I agree with the defaults you are proposing. How about the following?

1) nnoremap Y y$

2) Make UTF8 the default encoding.



What we can probably always do:

  " In many terminal emulators the mouse works just fine, thus enable it.
  if has('mouse')
set mouse=a
  endif


I would also set ttymouse=sgr when possible (but I do not know all the 
implications).


Nicola


--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups "vim_dev" group.

To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: Changing the defaults with Vim 8

[tyru]

Hi Bram!

2016-07-24 22:02 GMT+09:00 Bram Moolenaar :
>
> Vim has always been conservative about the default option values.
> Without any .vimrc the default is 'compatible'.  That's nice for people
> who rely on the old Vi.  But how many of these still exist?  I expect
> nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.
>
> What has stopped me from changing this is the unexpected change.  Many
> users will notice that Vim suddenly behaves differently.  Some may be
> upset.  The release of Vim 8.0 might be the best point in time to do
> this.  If we do this.
>
> Besides making 'nocompatible' the default, there are a few options that
> should probably be on by default.  Currently these are in
> $VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
> or slightly change how editing works.  You will notice this right away.
> The ones that have unexpected effects should be avoided.
>
> If someone wants to start in the old way, the -C flag should be used:
> vim -C
>
> If someone wants to start with 'nocompatible', but not all of the new
> option values, a .vimrc would be needed to change the settings.  This is
> the most common and also most tricky part.  Assuming that the user will
> want most of the new option values, but not all, he should be able to
> revert to the old value. For options that is easy.  But including the
> matchit plugin is not easy to revert.
>
> What we can probably always do:
>
>   set backspace=indent,eol,start
>   set history=50" keep 50 lines of command line history
>   set ruler " show the cursor position all the time
>   set showcmd   " display incomplete commands
>   set incsearch " do incremental searching
>
>   " Don't use Ex mode, use Q for formatting
>   map Q gq
>
>   " In many terminal emulators the mouse works just fine, thus enable it.
>   if has('mouse')
> set mouse=a
>   endif
>   if _Co > 2 || has("gui_running")
> syntax on
> set hlsearch
> let c_comment_strings=1
>   endif
>
>   if has("autocmd")
> " Enable file type detection.
> filetype plugin indent on
>
> augroup vimrcEx
> au!
>
> " For all text files set 'textwidth' to 78 characters.
> autocmd FileType text setlocal textwidth=78
>
> " When editing a file, always jump to the last known cursor position.
> " Don't do it when the position is invalid or when inside an event handler
> " (happens when dropping a file on gvim).
> autocmd BufReadPost *
>   \ if line("'\"") >= 1 && line("'\"") <= line("$") |
>   \   exe "normal! g`\"" |
>   \ endif
>
> augroup END
>   else
> set autoindent  " always set autoindenting on
>   endif
>
>   if has('langmap') && exists('+langnoremap')
> set langnoremap
>   endif
>
>
> Probably not:
>
>   " these two leave files behind
>   set backup
>   set undofile
>
>   " may conflict with a user mapping
>   inoremap  u
>
>   " hard to revert
>   if has('syntax') && has('eval')
> packadd matchit
>   endif
>
> Comments?

I want to propose the following settings additionally.


set ambiwidth=double
set display=lastline
set formatoptions+=j
set nrformats-=octal

let s:is_win = has('win16') || has('win32') || has('win64') || has('win95')
let s:is_msys = has('win32unix') && !has('gui_running')

" Exit diff mode automatically {{{
" https://hail2u.net/blog/software/vim-turn-off-diff-mode-automatically.html

augroup vimrc-diff-autocommands
  autocmd!

  " Turn off diff mode automatically
  autocmd WinEnter *
  \ if (winnr('$') == 1) &&
  \(getbufvar(winbufnr(0), '')) == 1 |
  \ diffoff   |
  \ endif
augroup END
" }}}

" Block cursor in MSYS2 console {{{
if s:is_msys
let _ti.="\e[1 q"
let _SI.="\e[5 q"
let _EI.="\e[1 q"
let _te.="\e[0 q"
endif
" }}}

" Input Method {{{
if has('multi_byte_ime') || has('xim')
" Set cursor color when IME is on.
highlight CursorIM guibg=Purple guifg=NONE
set iminsert=0 imsearch=0
endif
" }}}




>
> --
> TALL KNIGHT: When you have found the shrubbery, then you must cut down the
>  mightiest tree in the forest ... with a herring.
>  "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD
>
>  /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
> ///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
> \\\  an exciting new programming language -- http://www.Zimbu.org///
>  \\\help me help AIDS victims -- http://ICCF-Holland.org///
>
> --
> --
> You received this message from the "vim_dev" maillist.
> Do not top-post! Type your reply below the text you are replying to.
> For more information, visit http://www.vim.org/maillist.php
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "vim_dev" group.
> To unsubscribe from this group 

Changing the defaults with Vim 8

[Bram Moolenaar]

Vim has always been conservative about the default option values.
Without any .vimrc the default is 'compatible'.  That's nice for people
who rely on the old Vi.  But how many of these still exist?  I expect
nearly all Vim users to want 'nocompatible', thus create a .vimrc ASAP.

What has stopped me from changing this is the unexpected change.  Many
users will notice that Vim suddenly behaves differently.  Some may be
upset.  The release of Vim 8.0 might be the best point in time to do
this.  If we do this.

Besides making 'nocompatible' the default, there are a few options that
should probably be on by default.  Currently these are in
$VIMRUNTIME/vimrc_example.vim.  Most of these only have a visual effect
or slightly change how editing works.  You will notice this right away.
The ones that have unexpected effects should be avoided.

If someone wants to start in the old way, the -C flag should be used:
vim -C

If someone wants to start with 'nocompatible', but not all of the new
option values, a .vimrc would be needed to change the settings.  This is
the most common and also most tricky part.  Assuming that the user will
want most of the new option values, but not all, he should be able to
revert to the old value. For options that is easy.  But including the
matchit plugin is not easy to revert.

What we can probably always do:

  set backspace=indent,eol,start
  set history=50" keep 50 lines of command line history
  set ruler " show the cursor position all the time
  set showcmd   " display incomplete commands
  set incsearch " do incremental searching

  " Don't use Ex mode, use Q for formatting
  map Q gq

  " In many terminal emulators the mouse works just fine, thus enable it.
  if has('mouse')
set mouse=a
  endif
  if _Co > 2 || has("gui_running")
syntax on
set hlsearch
let c_comment_strings=1
  endif

  if has("autocmd")
" Enable file type detection.
filetype plugin indent on
  
augroup vimrcEx
au!
  
" For all text files set 'textwidth' to 78 characters.
autocmd FileType text setlocal textwidth=78
  
" When editing a file, always jump to the last known cursor position.
" Don't do it when the position is invalid or when inside an event handler
" (happens when dropping a file on gvim).
autocmd BufReadPost *
  \ if line("'\"") >= 1 && line("'\"") <= line("$") |
  \   exe "normal! g`\"" |
  \ endif
  
augroup END
  else
set autoindent  " always set autoindenting on
  endif
  
  if has('langmap') && exists('+langnoremap')
set langnoremap
  endif


Probably not:

  " these two leave files behind
  set backup
  set undofile

  " may conflict with a user mapping
  inoremap  u

  " hard to revert
  if has('syntax') && has('eval')
packadd matchit
  endif

Comments?

-- 
TALL KNIGHT: When you have found the shrubbery, then you must cut down the
 mightiest tree in the forest ... with a herring.
 "Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

 /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net   \\\
///sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org///
 \\\help me help AIDS victims -- http://ICCF-Holland.org///

-- 
-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

--- 
You received this message because you are subscribed to the Google Groups 
"vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to vim_dev+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.