Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Fri, Jul 10, 2020 at 03:28:22PM +, b0ns wrote:
> Hello,
> 
> I always refrained from extrapolating feedback or a complaint about this 
> issue but:
> It is now 3 years that i'm typing "set mouse=" every time I open a file with 
> VIM on debian while swearing!
> 
> Was this the intended result after this change?

You would need to talk to Bram about that, as I've previously stated in
this bug report.

> This settings is unmanageable for any debian system since stretch, we
> have hundreds of servers and we never managed to push through any
> workaround for this, not even have resources to invest on such change.

Presumably you're using some sort of orchestration, like Puppet.  In
that case, simply add "let g:skip_defaults_vim = 1" to
/etc/vim/vimrc.local, as is documented in this bug report,
NEWS.Debian.gz, and /etc/vim/vimrc.

> It doesn't seem there is any advantage and people is constantly
> swearing about this debian change every time they open VIM, not only
> me!

This is NOT a Debian-specific change.  It is an upstream change, which I
have argued against many times because of many of the issues raised here
and in other bug reports.  Bram has refused to accept my suggestions,
basically stating that "changing it now would break people's configs
that are used to it".

I'm just as frustrated as everyone else with the way this was
implemented, but this is not something I'm going to change just in
Debian.

This is one of many reasons that I generally use neovim now, rather than
Vim.

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

Bug#864074: defaults.vim: broken configuration

[b0ns]

Hello,

I always refrained from extrapolating feedback or a complaint about this issue 
but:
It is now 3 years that i'm typing "set mouse=" every time I open a file with 
VIM on debian while swearing!

Was this the intended result after this change?

This setting broke things and that's it, I wonder where the improvement has 
been and for who.

This settings is unmanageable for any debian system since stretch, we have 
hundreds of servers and we never managed to push through any workaround for 
this, not even have resources to invest on such change.

It doesn't seem there is any advantage and people is constantly swearing about 
this debian change every time they open VIM, not only me! every colleague or 
person working with debian is reporting the same problem and swearing about 
this change and why it went through.

So I would like to gently ask to SERIOUSLY review the situation about this and 
EVALUATE AGAIN to go toward an upstream change to restore NORMAL USABILITY for 
99% of the users and companies using debian systems.

If after 3 years we are still typing "set mouse=" (every time I open a file 
with vim) ,like many other users do ,there must be a reason and really a big 
problem somewhere!

to not even mention people falling back to CAT for copying the content of a 
file, or even NANO just because of this change.



signature.asc
Description: OpenPGP digital signature

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Dear James.

James McCoy - 06.07.17, 03:09:23 CEST:
> > 3) Vim wordwraps by default now. I wonder about how many admins will
> > break config files with long lines accidently by that new default
> > behaviour.
> I don't see anything in defaults.vim that changes 'textwidth' from its
> default value of 0, so I'm not sure what you're experiencing here.
> Maybe ":verbose set textwidth?" will help next time you run into this
> issue.

Finally I found this one. It is:

% grep filetype /usr/share/vim/vim82/defaults.vim 
" Use the default filetype settings, so that mail gets 'tw' set to 72,
" Revert with ":filetype off".
filetype plugin indent on

It triggers for example for editing Git commit messages. And no, I don't 
like command line output to be wrapped in there.

Thus I did:

% cat /etc/vim/vimrc.local 
[…]
" 'set mouse=' in /etc/vim/vimrc.local is ignored unless ~/.vimrc exists
" https://bugs.debian.org/864074
runtime! defaults.vim
let g:skip_defaults_vim = 1
[…]
:filetype plugin indent off
[…]

Let's hope no other unexpected configuration changes creep in by using 
defaults.vim – otherwise I may reconsider having 'runtime! defaults.vim' 
in 'vimrc.local', so far I am not sure it gives me any substantial 
benefits over just using my own configuration.

I am also not sure whether I really like incremental search so far. 
Let's see.

I am still not convinced that the current handling of 'vimrc.local' is 
Debian user friendly.

Ciao,
-- 
Martin

Bug#864074: defaults.vim: broken configuration

[Rudi Daemen]

Hi all,

For all of those that are googling for this issue and want a quick 
work-around in place until the order-of-inclusion is fixed upstream, I 
have added the following two lines to the beginning of the system-wide 
vimrc.local on all debian servers I am managing:


runtime! defaults.vim
let g:skip_defaults_vim = 1

The first line, ofcourse, is only needed if you actually want some of 
the values from the "defaults.vim" file, otherwise it can be omitted. 
The second line avoids it from being loaded again at any later stage. I 
can confirm this works as it does load the defaults.vim (and thus some 
config options I do like) but it does this before processing the 
remainder in vimrc.local. As a result, it now no longer overrides any 
config options I did not like and thus changed in vimrc.local (e.g. set 
mouse=).


Just adding these two lines to the vimrc.local file resolved my problems 
with vim.


Kind regards,
Rudi

Bug#864074: defaults.vim: broken configuration

[Mark Abrahams]

Hi

On Thu, 20 Jul 2017 22:24:01 -0400 James McCoy  wrote:
> On Thu, Jul 20, 2017 at 03:46:39PM -0700, Adam Waite wrote:
> > As mentioned on other bug reports, this is an order-of-inclusion 
issue.

> >
> >   1: /usr/share/vim/vimrc
> >   2: /usr/share/vim/vim80/debian.vim
> >   3: /etc/vim/vimrc.local
> >   4: /usr/share/vim/vim80/defaults.vim
> >   [snip]
> >
> > defaults.vim is being loaded *after* vimrc.local, which means that 
vimrc.local

> > is useless for overriding the package default settings. This is not the
> > expected behavior.
> >
> > The solution is simple, and it is simply baffling that it has been 
resisted by
> > the package maintainers. Why should users have to completely 
disable the

> > defaults, just to disable a single problematic configuration item?
>
> There's no need to disable defaults.vim. As I have also suggested (in
> this very bug report), you can explicitly load defaults.vim and then
> disable whatever settings you don't like.
>
> Changing this behavior _just_ for Debian will only add to the confusion,
> since users will now get different behavior on different systems.
> Upstream needs to be convinced that this is a problem, so it can be
> addressed there.
>
> Cheers,
> --
> James
> GPG Key: 4096R/91BF BF4D 6956 BD5D F7B7 2D23 DFE6 91AE 331B A3DB
>
>

Thanks for your helpful explanation on the issue here James, but let me 
add my agreement to the general sentiment in this thread: I believe that 
the vim behavior here is problematic to the point of warranting a change 
in the Debian package.


Forgive the proceeding monologue, but I'll try to illustrate with my 
case. I'm doing my first build of a stretch rollout, which involves 
building and populating LDAP, so no user accounts at this point - all 
just root and an "ansible" user to get things started.  Just wanting to 
get things done, I'm a little disappointed when I discover that 
mouse-based copy to the system clipboard is broken. It annoys me, but 
with the actual in-flight task at hand of building LDAP, etc., and a 
complete lack of appetite to fight vim, I make the shortsighted decision 
to work around this by exiting vim and cat'ing/grep'ing whenever I want 
to copy stuff out of a file.  At some point the annoyance threshold for 
this productivity hit is breached - and I stop what I'm doing to 
research and find the "set mouse=" workaround.  I confirm this works in 
running vim, and then add to /etc/vim/vimrc.local.  Which doesn't work.  
I'm off-task now anyway, so I keep googling my way ultimately to this 
thread - which is fanastic BTW - read the note about defaults.vim at the 
top of the system vimrc file, make a guess at what $VIMRUNTIME is, find 
defaults.vim, find the "set mouse=a" line in the defaults, confirming 
that is overriding my vimrc.local setting, add "let g:skip_defaults_vim 
= 1" to vimrc.local, and the copy function is permanently restored.  I 
then write up a quick ansible role to fix this across all systems, test 
the role, and roll it out.  Then write this email, due to some strong 
but hopefully helpful feelings on the subject.  Time wasted all up: 
probably about 2 hours, some of it due to a with-hindsight poor decision 
to not troubleshoot and fix the issue immediately.  I'd hazard a guess 
that I'm a reasonably typical engineer here, just wanting to get work 
done with tools that had worked for me previously.  So multiply that 
sort of time wasted by the number of people hitting the same thing 
first-time installing stretch.


Compare that with the potential confusion you have sighted with 
cross-system consistency with a divergence from upstream:
(a) I'd wager that the amount of collective time waste would pale in 
comparison to that inherent in the the current situation, and
(b) any confusion issues aren't Debian's problem, if you make Debian 
work how 99% of the user base would expect.  The onus is on other system 
owners to provide a good experience for their user base.


Debian working in an intuitive way carries less confusion than Debian 
working in a completely counterintuitive and counterproductive way 
consistent with an upstream.


Kind regards
Mark

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Martin Steigerwald - 21.07.17, 14:53:
> The issue is, that it is required to have a work-around like this, or the
> one  James suggested – where it will if I understand correctly load
> defaults.vim before making changes to it –, in order to have a sane
> behavior. Since I use Linux, configuration loading always worked from
> global to local. Here it does not, unless you add a work-around.
> 
> This has been an upstream decision according to James and I think its best
> to  bring this issue to upstream. If upstream does not adapt the behavior,
> I am all for a patch in the Debian package, but it seems James thinks
> differently on that one. Another option would be to vote about that new
> behavior by switching to neovim.

I tested configuration for neovim by copying contents of /etc/vim/vimrc.local 
to /etc/xdg/nvim/init.vim (strange location for config file if you ask me) and 
removing the defaults.vim work-around. This basically works just fine. I just 
did "set mouse=" as neovim also enables it by default. But nvim respects this 
without any work-around. It doesn´t seem to have the defaults.vim thing.

I also used update-alternatives --config vim to switch to nvim by default.

Lets see how that works.

This will just be my work-around for my laptop for now.

-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Fri, Jul 21, 2017 at 02:25:46PM +0200, Igor Sverkos wrote:
> Hi,
> 
> On Thu, 20 Jul 2017 22:24:01 -0400 James McCoy  wrote:
> 
> > There's no need to disable defaults.vim.  As I have also suggested (in
> > this very bug report), you can explicitly load defaults.vim and then
> > disable whatever settings you don't like.
> 
> I hit the same problem. Maybe I don't understand your suggestion. Could
> you please explain it in more details?
> 
> My problem:
> ===
> We have a network running ~600 Debian boxes at the moment.
> 
> We are using Puppet for configuration management.
> 
> I now want to deploy a default system-wide VIM configuration which can
> be overwritten by the user using ~/.vimrc.
> 
> How am I supposed to do that?

See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=864074#40

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

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Igor Sverkos - 21.07.17, 14:25:
> Hi,
> 
> On Thu, 20 Jul 2017 22:24:01 -0400 James McCoy  wrote:
> > There's no need to disable defaults.vim.  As I have also suggested (in
> > this very bug report), you can explicitly load defaults.vim and then
> > disable whatever settings you don't like.
> 
> I hit the same problem. Maybe I don't understand your suggestion. Could
> you please explain it in more details?
> 
> My problem:
> ===
> We have a network running ~600 Debian boxes at the moment.
> 
> We are using Puppet for configuration management.
> 
> I now want to deploy a default system-wide VIM configuration which can
> be overwritten by the user using ~/.vimrc.
> 
> How am I supposed to do that?
> 
> I would expect to alter "/etc/vim/vimrc" respective
> "/etc/vim/vimrc.local" but this doesn't work when
> "/usr/share/vim/vim80/defaults.vim" will be sourced as last
> configuration file.

Well that one is actually documented in README.Debian as pointed out here in 
this bug report several times already. Add

let g:skip_defaults_vim = 1

at the beginning of "/etc/vim/vimrc.local".

And that is not really the issue of this bug report.

The issue is, that it is required to have a work-around like this, or the one 
James suggested – where it will if I understand correctly load defaults.vim 
before making changes to it –, in order to have a sane behavior. Since I use 
Linux, configuration loading always worked from global to local. Here it does 
not, unless you add a work-around.

This has been an upstream decision according to James and I think its best to 
bring this issue to upstream. If upstream does not adapt the behavior, I am 
all for a patch in the Debian package, but it seems James thinks differently 
on that one. Another option would be to vote about that new behavior by 
switching to neovim.

Thanks,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Bug#864074: defaults.vim: broken configuration

[Igor Sverkos]

Hi,

On Thu, 20 Jul 2017 22:24:01 -0400 James McCoy  wrote:

> There's no need to disable defaults.vim.  As I have also suggested (in
> this very bug report), you can explicitly load defaults.vim and then
> disable whatever settings you don't like.

I hit the same problem. Maybe I don't understand your suggestion. Could
you please explain it in more details?

My problem:
===
We have a network running ~600 Debian boxes at the moment.

We are using Puppet for configuration management.

I now want to deploy a default system-wide VIM configuration which can
be overwritten by the user using ~/.vimrc.

How am I supposed to do that?

I would expect to alter "/etc/vim/vimrc" respective
"/etc/vim/vimrc.local" but this doesn't work when
"/usr/share/vim/vim80/defaults.vim" will be sourced as last
configuration file.


-- 
Regards,
Igor

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Thu, Jul 20, 2017 at 03:46:39PM -0700, Adam Waite wrote:
> As mentioned on other bug reports, this is an order-of-inclusion issue. 
> 
>   1: /usr/share/vim/vimrc
>   2: /usr/share/vim/vim80/debian.vim
>   3: /etc/vim/vimrc.local
>   4: /usr/share/vim/vim80/defaults.vim
>   [snip]
> 
> defaults.vim is being loaded *after* vimrc.local, which means that vimrc.local
> is useless for overriding the package default settings. This is not the
> expected behavior. 
> 
> The solution is simple, and it is simply baffling that it has been resisted by
> the package maintainers. Why should users have to completely disable the
> defaults, just to disable a single problematic configuration item? 

There's no need to disable defaults.vim.  As I have also suggested (in
this very bug report), you can explicitly load defaults.vim and then
disable whatever settings you don't like.

Changing this behavior _just_ for Debian will only add to the confusion,
since users will now get different behavior on different systems.
Upstream needs to be convinced that this is a problem, so it can be
addressed there.

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

Bug#864074: defaults.vim: broken configuration

[Adam Waite]

As mentioned on other bug reports, this is an order-of-inclusion issue.

  1: /usr/share/vim/vimrc
  2: /usr/share/vim/vim80/debian.vim
  3: /etc/vim/vimrc.local
  4: /usr/share/vim/vim80/defaults.vim
  [snip]

defaults.vim is being loaded *after* vimrc.local, which means that
vimrc.local is useless for overriding the package default settings. This is
not the expected behavior.

Suggesting that each individual user on a system should supply their own
.vimrc is a ridiculous non-solution, especially since the functionality
exists to set system-wide defaults.

Prematurely closed bugs:
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837761
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=837880

The solution is simple, and it is simply baffling that it has been resisted
by the package maintainers. Why should users have to completely disable the
defaults, just to disable a single problematic configuration item?

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

James, did you intend to send this just to me? To be on safe side, I reply to 
you only, but I really think this should also go to the bug report.

James McCoy - 18.07.17, 20:21:
> On Sat, Jul 08, 2017 at 11:36:07PM +0200, Martin Steigerwald wrote:
> > James McCoy - 05.07.17, 21:09:
[…]
> > My order wasn´t complete. I think it should be:
> > 
> > 1. Global vim configuration
> > 2. /etc/vim/vimrc.local
> > 3. $HOME/.vimrc
> > 4. defaults.vim
> > 
> > so that defaults.vim can only ever set any setting that has *not* been set
> > by any of the other configuration files.
> 
> Then you would actually want defaults.vim to be first, so that anything
> else set overrides it.  You can do exactly that by putting this in your
> /etc/vim/vimrc.local:
> 
> " Explicitly source defaults.vim so you can override its settings
> source $VIMRUNTIME/defaults.vim
> " Prevent it from being loaded again later if the user doesn't have
> " a vimrc
> let skip_defaults_vim = 1

And all that just to restore some sanity to the VIM configuration… well…

> > It is completely unintuitive that defaults.vim overwrites settings in
> > vimrc.local by default. If I write "set mouse=" in there, I mean it. I
> > really dislike software that pretends it knows better than me unless I
> > tell that software to stop that behavior.
> > 
> > Never *ever* overwrite user/admin made settings.
> 
> Yes, that was another part that Bram just punted on when he was deciding
> how defaults.vim would work.

I may look at a vim fork that doesn´t adopt this nonsense.

> > > defaults.vim is intentionally loaded _after_ $HOME/.vimrc so that Vim
> > > can choose not to load it when $HOME/.vimrc exists.  The situation
> > > you're running into is that you don't have $HOME/.vimrc and therefore
> > > are having the system-wide values adjusted by defaults.vim.
> > 
> > Alternatively vim should not load defaults.vim if vimrc.local exists I
> > think.
> /etc/vim/vimrc is the only thing Vim knows about.  It just happens to
> have a snippet at the end which sources /etc/vim/vimrc.local.
> 
> If anything, I'll add a commented out version of the code I posted
> above to /etc/vim/vimrc.  I thought this sort of stuff would be easily
> figured out for people that wanted to customize the behavior, but
> apparently I was wrong.

This is… I already use "let skip_defaults_vim = 1". I found this before 
already, and I think apt-listchanges showed me your update to NEWS.Debian.

But the issue with this is: Now by default the VIM configuration is *broken* in 
several ways which I described on *every* newly installed *or* upgraded Debian 
system. Which needs adapting the configuration every newly installed system.

For *what* benefit?

Well, I bet I´d need to file an issue with upstream about that.

Thanks,
-- 
Martin

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Sat, Jul 08, 2017 at 11:36:07PM +0200, Martin Steigerwald wrote:
> James McCoy - 05.07.17, 21:09:
> > This _is_ the behavior.  The _only_ way that defaults.vim is used is
> > when $HOME/.vimrc doesn't exist.
> > 
> > Note that /etc/vim/vimrc.local is a Debian-specific extension of the
> > system-wide vimrc, to avoid conffile prompts during upgrades, so 1 & 2
> > are the same thing.
> 
> My order wasn´t complete. I think it should be:
> 
> 1. Global vim configuration
> 2. /etc/vim/vimrc.local
> 3. $HOME/.vimrc
> 4. defaults.vim
> 
> so that defaults.vim can only ever set any setting that has *not* been set by 
> any of the other configuration files.

Then you would actually want defaults.vim to be first, so that anything
else set overrides it.  You can do exactly that by putting this in your
/etc/vim/vimrc.local:

" Explicitly source defaults.vim so you can override its settings
source $VIMRUNTIME/defaults.vim
" Prevent it from being loaded again later if the user doesn't have
" a vimrc
let skip_defaults_vim = 1
" Disable the settings you don't like
set mouse=

> It is completely unintuitive that defaults.vim overwrites settings in 
> vimrc.local by default. If I write "set mouse=" in there, I mean it. I really 
> dislike software that pretends it knows better than me unless I tell that 
> software to stop that behavior.
> 
> Never *ever* overwrite user/admin made settings.

Yes, that was another part that Bram just punted on when he was deciding
how defaults.vim would work.

> > defaults.vim is intentionally loaded _after_ $HOME/.vimrc so that Vim
> > can choose not to load it when $HOME/.vimrc exists.  The situation
> > you're running into is that you don't have $HOME/.vimrc and therefore
> > are having the system-wide values adjusted by defaults.vim.
> 
> Alternatively vim should not load defaults.vim if vimrc.local exists I think.

/etc/vim/vimrc is the only thing Vim knows about.  It just happens to
have a snippet at the end which sources /etc/vim/vimrc.local.

If anything, I'll add a commented out version of the code I posted
above to /etc/vim/vimrc.  I thought this sort of stuff would be easily
figured out for people that wanted to customize the behavior, but
apparently I was wrong.

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

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Wed, Jul 19, 2017 at 11:38:40PM +0200, Martin Steigerwald wrote:
> James, did you intend to send this just to me?

I didn't.

> To be on safe side, I reply to 
> you only, but I really think this should also go to the bug report.

Agreed. I'll bounce the last two messages to the bug.

> James McCoy - 18.07.17, 20:21:
> > On Sat, Jul 08, 2017 at 11:36:07PM +0200, Martin Steigerwald wrote:
> > > James McCoy - 05.07.17, 21:09:
> […]
> > > My order wasn´t complete. I think it should be:
> > > 
> > > 1. Global vim configuration
> > > 2. /etc/vim/vimrc.local
> > > 3. $HOME/.vimrc
> > > 4. defaults.vim
> > > 
> > > so that defaults.vim can only ever set any setting that has *not* been set
> > > by any of the other configuration files.
> > 
> > Then you would actually want defaults.vim to be first, so that anything
> > else set overrides it.  You can do exactly that by putting this in your
> > /etc/vim/vimrc.local:
> > 
> > " Explicitly source defaults.vim so you can override its settings
> > source $VIMRUNTIME/defaults.vim
> > " Prevent it from being loaded again later if the user doesn't have
> > " a vimrc
> > let skip_defaults_vim = 1
> 
> And all that just to restore some sanity to the VIM configuration… well…

I understand the feeling, but I also dislike deviating from default
configurations since that makes it harder for people to switch between
systems.  That's why I've suggested raising the issue upstream.

> > > It is completely unintuitive that defaults.vim overwrites settings in
> > > vimrc.local by default. If I write "set mouse=" in there, I mean it. I
> > > really dislike software that pretends it knows better than me unless I
> > > tell that software to stop that behavior.
> > > 
> > > Never *ever* overwrite user/admin made settings.
> > 
> > Yes, that was another part that Bram just punted on when he was deciding
> > how defaults.vim would work.
> 
> I may look at a vim fork that doesn´t adopt this nonsense.

Neovim bakes in saner defaults, which avoids all this jumping through
hoops when you want to deviate from them.

> But the issue with this is: Now by default the VIM configuration is *broken* 
> in 
> several ways which I described on *every* newly installed *or* upgraded 
> Debian 
> system. Which needs adapting the configuration every newly installed system.
> 
> For *what* benefit?

Many of the changes *are* useful to enable, but 'mouse' in particular
was a poor choice and the interaction with system-wide vimrc was an even
poorer one.

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

Bug#864074: defaults.vim: broken configuration

[gisl]

I can only agree with Martin.

Getting your local configuration overwritten is very irritating and 
unexpected. Defaults are there to be overridden by local configuration, not 
the other way round.

The broken copy scenario needs fixing on *every* headless Debian Stretch 
installation, which is very tedious.

Thanks
Carsten

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Dear James.

Thank you for your detailed answer.

James McCoy - 05.07.17, 21:09:
> On Wed, Jul 05, 2017 at 09:55:06PM +0200, Martin Steigerwald wrote:
> > Dear Maintainer.
> > 
> > I know of this:
> > > Vim will load $VIMRUNTIME/defaults.vim if the user does not have a
> > > vimrc.
> > > This happens after /etc/vim/vimrc(.local) are loaded, so it will
> > > override
> > > any settings in these files.
> > 
> > But the settings in "defaults.vim" IMHO are just *completely* broken for
> > several reasons:
> > 
> > 1) Maybe due to a bug in Vim regarding mouse handling with "set mouse=a"
> > Vim is just madly moving around the cursor and doing whatelse not for
> > easily a minute in a lot of freshly installed Debian 9 VMs accesses via
> > SSH and screen from Plasma´s Konsole terminal emulator.
> 
> These problems are more typically due to people/software setting
> incorrect values for $TERM and/or related options in Vim ('ttymouse',
> 'term', etc.).  Vim can only act on the information it has, so when
> that's incorrect -- garbage in, garbage out.

$TERM is "xterm-256color" in console.

> That being said, "set mouse=a" _is_ one setting I argued against
> upstream.  I would encourage you to post your experiences and reasoning
> against that setting to v...@vim.org.  I'd rather see this changed
> upstream instead of piecewise changing parts of defaults.vim.

I am not sure I want to do this.

> > 3) Vim wordwraps by default now. I wonder about how many admins will break
> > config files with long lines accidently by that new default behaviour.
> 
> I don't see anything in defaults.vim that changes 'textwidth' from its
> default value of 0, so I'm not sure what you're experiencing here.
> Maybe ":verbose set textwidth?" will help next time you run into this
> issue.

I have seen it word-wrap, well now I disabled defaults.vim on all my systems. 
I comment out the disabling on one system. I may do so next week. On my laptop 
I also have ~/.vimrc files.

> > I think it is broken behaviour, that "defaults.vim" is loaded *after*
> > "vimrc.local". The sane default would be this order:
> > 
> > 1. Global vim configuration
> > 2. /etc/vim/vimrc.local
> > 3. $HOME/.vimrc
> 
> This _is_ the behavior.  The _only_ way that defaults.vim is used is
> when $HOME/.vimrc doesn't exist.
> 
> Note that /etc/vim/vimrc.local is a Debian-specific extension of the
> system-wide vimrc, to avoid conffile prompts during upgrades, so 1 & 2
> are the same thing.

My order wasn´t complete. I think it should be:

1. Global vim configuration
2. /etc/vim/vimrc.local
3. $HOME/.vimrc
4. defaults.vim

so that defaults.vim can only ever set any setting that has *not* been set by 
any of the other configuration files.

It is completely unintuitive that defaults.vim overwrites settings in 
vimrc.local by default. If I write "set mouse=" in there, I mean it. I really 
dislike software that pretends it knows better than me unless I tell that 
software to stop that behavior.

Never *ever* overwrite user/admin made settings.

> defaults.vim is intentionally loaded _after_ $HOME/.vimrc so that Vim
> can choose not to load it when $HOME/.vimrc exists.  The situation
> you're running into is that you don't have $HOME/.vimrc and therefore
> are having the system-wide values adjusted by defaults.vim.

Alternatively vim should not load defaults.vim if vimrc.local exists I think.

Thanks,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.

Bug#864074: defaults.vim: broken configuration

[James McCoy]

On Wed, Jul 05, 2017 at 09:55:06PM +0200, Martin Steigerwald wrote:
> Dear Maintainer.
> 
> I know of this:
> 
> > Vim will load $VIMRUNTIME/defaults.vim if the user does not have a vimrc.
> > This happens after /etc/vim/vimrc(.local) are loaded, so it will override
> > any settings in these files.
> But the settings in "defaults.vim" IMHO are just *completely* broken for 
> several reasons:
> 
> 1) Maybe due to a bug in Vim regarding mouse handling with "set mouse=a" Vim 
> is just madly moving around the cursor and doing whatelse not for easily a 
> minute in a lot of freshly installed Debian 9 VMs accesses via SSH and screen 
> from Plasma´s Konsole terminal emulator.

These problems are more typically due to people/software setting
incorrect values for $TERM and/or related options in Vim ('ttymouse',
'term', etc.).  Vim can only act on the information it has, so when
that's incorrect -- garbage in, garbage out.

That being said, "set mouse=a" _is_ one setting I argued against
upstream.  I would encourage you to post your experiences and reasoning
against that setting to v...@vim.org.  I'd rather see this changed
upstream instead of piecewise changing parts of defaults.vim.

> 2) Activated mouse handling breaks copy and paste text from Plasma´s 
> clipboard 
> by… auto-indenting and what else not. I know of "set nopaste" (or what else 
> it 
> was called)… but having to activate it is an additional nuisance.

This should actually behave better once I'm able to upload a newer
version of Vim, since it knows how to use bracketed paste mode.

> 3) Vim wordwraps by default now. I wonder about how many admins will break 
> config files with long lines accidently by that new default behaviour.

I don't see anything in defaults.vim that changes 'textwidth' from its
default value of 0, so I'm not sure what you're experiencing here.
Maybe ":verbose set textwidth?" will help next time you run into this
issue.

> I think it is broken behaviour, that "defaults.vim" is loaded *after* 
> "vimrc.local". The sane default would be this order:
> 
> 1. Global vim configuration
> 2. /etc/vim/vimrc.local
> 3. $HOME/.vimrc

This _is_ the behavior.  The _only_ way that defaults.vim is used is
when $HOME/.vimrc doesn't exist.

Note that /etc/vim/vimrc.local is a Debian-specific extension of the
system-wide vimrc, to avoid conffile prompts during upgrades, so 1 & 2
are the same thing.

defaults.vim is intentionally loaded _after_ $HOME/.vimrc so that Vim
can choose not to load it when $HOME/.vimrc exists.  The situation
you're running into is that you don't have $HOME/.vimrc and therefore
are having the system-wide values adjusted by defaults.vim.

That behavior is the entire reason why I added documentation to
/etc/vim/vimrc (which one has to read to know about vimrc.local) about
how to deal with defaults.vim.

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

Bug#864074: defaults.vim: broken configuration

[Martin Steigerwald]

Dear Maintainer.

I know of this:

> Vim will load $VIMRUNTIME/defaults.vim if the user does not have a vimrc.
> This happens after /etc/vim/vimrc(.local) are loaded, so it will override
> any settings in these files.

But the settings in "defaults.vim" IMHO are just *completely* broken for 
several reasons:

1) Maybe due to a bug in Vim regarding mouse handling with "set mouse=a" Vim 
is just madly moving around the cursor and doing whatelse not for easily a 
minute in a lot of freshly installed Debian 9 VMs accesses via SSH and screen 
from Plasma´s Konsole terminal emulator.

2) Activated mouse handling breaks copy and paste text from Plasma´s clipboard 
by… auto-indenting and what else not. I know of "set nopaste" (or what else it 
was called)… but having to activate it is an additional nuisance.

3) Vim wordwraps by default now. I wonder about how many admins will break 
config files with long lines accidently by that new default behaviour.

These defaults may be somewhat suitable for a desktop editor, but for Vim I 
think they are just plain broken. So I kindly ask you reconsider applying this 
broken configuration… or at least consider restoring a sane order in which Vim 
applies configuration:

I think it is broken behaviour, that "defaults.vim" is loaded *after* 
"vimrc.local". The sane default would be this order:

1. Global vim configuration
2. /etc/vim/vimrc.local
3. $HOME/.vimrc

The current order is a cross disrespect and paternalism for the local site 
admin.

The order vim uses now makes it necessary for me to add

let g:skip_defaults_vim = 1

to *any* newly installed Debian 9 system.

In addition to "screen" this is the second new default config that breaks 
existing setups.

Thank you,
-- 
Martin

signature.asc
Description: This is a digitally signed message part.