Hi
On Thu, 20 Jul 2017 22:24:01 -0400 James McCoy <james...@debian.org> 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
