Hello James,
I am disappointed in your dismissal of these two tickets. Allow me to make the
case why you should reconsider. I will point out that firstly, it actually is
the responsibility of Debian's package-maintainer to make this change, and
secondly, that my proposed solution will not interfere with most of the user
base, while certainly enhancing the experience for a small but significant
minority. If done right, and upstream makes a reasonable modification, say in
vim 8.2, you simply do not need to include the proposed addition and everything
should work fine. Together these arguments should effectively undermine your
stated response as to why no action will be taken.
First, a distribution packager's primary responsibility is to ensure that
upstream software is compatible with the other components compiled and
installed for that distribution. Of close secondary consideration is to ensure
that newer versions are configured or customized in a way that does not disrupt
the user experience, and if possible, enhances it. After all, we hope software
upgrades also upgrade stability, user-experience, etc. There are also
prerequisites of course, such as the software being open-source, and that the
build process itself is open. If your view of what packages is at significance
variance with the above, then please point out to me some document or blog
which you follow as your guiding principles.
Second point is that software vendors provide software configured for what they
consider are typical use-cases, but by no means do they expect downstream
packagers to keep the settings as-is. Indeed, they often expect packagers and
site-administrators to fine-tune the settings for their audience. It is the
**domain of configuring defaults and system configuration files is that of the
packager and not the software provider**. This is true, whether it be Apache
httpd, the gnu compiler, the dhcp daemon, the linux kernel. Vim provides
software to all platforms, and it is up to each distribution to individualize
and configure the package for their users' best interests. Sometime, such
settings are incorporated into the original distribution. Is Debian.vim one of
those or are these customized by the packager? Either way, the case is clear
that a Debian installation of vim is not the same as the general distribution
of vim.
Therefore, it is clear, that the Debian packagers are to set and configure
vim's settings so that its users have a satisfying user-experience with those
default settings. And it is this very point that you have two complainants
saying very clearly, this is not the status quo, and are therefore begging you
to change it. Believe me, there are many more of us, but you won't notice them
as much for reasons I will point out below.
It is further the case that at least some settings in debian.vim are overridden
by those in defaults.vim. This is clearly against the design and wishes of
prior packagers!
So before I re-present the solution, let's talk about the use cases. Your
dismissal of our tickets suggests you know only one or typical use-cases of the
vim package. I suspect the most common use-case for this Debian-vim package is
to be installed as an upgrade an existing, Debian installation, for which the
user is already familiar with vim and has already created their own .vimrc for
customization. For such a user, an X-based interface is almost a given, which
means vim might very well run not in a terminal but in an X Window. Most of
these users are unaffected by the very annoying "mouse" setting because either
they have their own .vimrc or they are using vim within X-Windows. And in
these vast majority of such cases, there will be very little need to override
system-wide defaults in something like a /etc/vimrc or /etc/vimrc.local file.
From that point of view, I understand your dismissal.
However, quite a few of us need to install and support Debian workstations
across an organization, or multi-user servers, For us and for the sake of our
users, we need the ability to make a system-wide setting. We would naturally
put those changes in either /etc/vim/vimrc or as suggested in that file
/etc/vim/vimrc.local. In fact, we may already have put those settings there.
And expect them to work. Or as is often my case, I must modify a Docker
container which runs Debian but has been stripped of all but essential
packages, and which I must try out a few ad hoc changes before updating the
Dockerfile. For that case, I must install vim, and then I must make some
setting changes in /etc/vim/vimrc and lo and behold, those changes don't work.
Well, some of them might, others not, who knows? And it will take tons of
digging around as I and many others have done to fix that.
Thus, the provided /usr/share/vim/vimrc is *plainly incorrect* in one of two
ways. First the opening comment, it suggests that "all system-wide defaults"
are set in the Debian.vim file. But now we know this is incorrect, as the new
upstream version loads defaults.vim after processing this file, clobbering
those defaults from Debian.vim and those set in this file. Second, it indicates
that "this file" is where you should make system-wide setttings that override
those in Debian.vim. However, "this file" is actually a softlink to
/etc/vim/vimrc. (Why? I don't understand why it's a softlink when it does at
the end a "source /etc/vim/vimrc.local". Will this file get replaced on an
update? I'm guessing it will be replaced unless that file is changed, so why
have a vimrc.local? It would have been better to leave this as is in
/usr/share/vim/vimrc and include /etc/vim/vimrc. However, this is not
something I am requesting or suggesting at this time -- but it may be the
better route to take, see below.)
And so it is for the sake of your future users, and my future self and my
fellow devops engineers and system admins that this load-order should be
corrected to go along with long-established software norms and established vim
behavior: defaults should not override package- and site-settings. And yeah, I
think vim devs should effectively undo that "feature" which reads defaults.vim
last, but we cannot count on them, we don't have to wait for it, and this is
ultimately the packager's responsibility anyway.
I hope this conclusively motivates you to make the change to the debian vim
package.
---
The solution I proposed will not affect existing users.
Apparently to convince you of that, I must first refute your rebuttal to my
assertion that :version represents the order of files loaded. In fact, :version
does show that order! Perhaps it is circumstance, but I do not think so. I have
used strace in varying conditions to prove that (provided at the end of this
email). The defaults.vim file are read *last* _unless_ a user has an existing
$HOME/.vimrc or $HOME/.vim/vimrc, even an empty one. The existence of
/usr/share/vim/vimrc (or the sourced vimrc.local from it) has no impact on that
read-order, as that file is always read first. In reading that file, debian.vim
is read. If there are any settings made there, but the user has no .vimrc file,
then they are overridden by defaults.vim.
I originally proposed that you modify /etc/vim/vimrc. However, that was based
off the vim bug report, and is not IMO correct here. The problem is that the
ill-conceived behavior will continue despite a (minor) upgrade of the package.
Instead, therefore, I believe it should be made in the vim81/debian.vim file.
Alternatively, you could make /usr/share/vim/vimrc be a real file which sources
/etc/vim/vimrc as is the norm, and include this proposed change early in the
/usr/share/vim/vimrc file.
The change I propose is thus the following, near the top of the file, _before_
the "runtime debian.vim" line.
:if ! filereadable(expand('~/.vimrc')) && ! filereadable(expand('~/.vim/vimrc'))
: source $VIMRUNTIME/defaults.vim
: let g:skip_defaults_vim = 1
:endif
For users with a .vimrc, nothing will change.
For users without a .vimrc file, the defaults file will be read. However, now,
it will be read _first_ before the rest of this file and the other site-wide
vimrc files (eg, vim.local) are processed. The defaults file will _not_ be
read again.
Thus, for users who are happy with the system defaults and have no .vimrc,
nothing will change UNLESS those defaults were overridden by settings in
debian.vim, as now the debian.vim settings will have the intended effect. It is
very likely users already noticed this change with the latest upgrade, and
reapplied desired changes to their .vimrc files. So, again, nothing will change
that those users cared about.
For users who made changes in /etc/vim/vimrc or /etc/vim/vimrc.local, thos
changes may suddenly have an effect where they didn't before. This could be a
pleasant surprise.
For users who already made a similar work-around for this problem, it will also
not have an effect. Once the skip_defaults_vim is set, it won't get re-set.
For first-time installers, vim will operate exactly as it does without the
modification -- until the installer decides to change something in a side-wide
vimrc. And that is how it should be.
So, you see, it's win-win for nearly every conceivable scenario.
=== Appendix : strace of stat calls with vim ====
A. As the root user, which has no .vimrc file, vim attempted to load the
files in the following order:
/usr/share/vim/vimrc
(With !runtime debian.vim)
/root/.vim/debian.vim [ENOENT]
/etc/vim/debian.vim [ENOENT]
/usr/share/vim/vimfiles/debian.vim [ENOENT]
/usr/share/vim/vim81/debian.vim
/usr/share/vim/vimfiles/after/debian.vim [ENOENT]
/etc/vim/after/debian.vim [ENOENT]
/root/.vim/after/debian.vim [ENOENT]
/etc/vim/vimrc.local
<local directory check>
/root/.vimrc [ENOENT]
/root/.vim/vimrc [ENOENT]
/root/.exrc [ENOENT]
/usr/share/vim/vim81/defaults.vim <--- BOO HISSS
...
(then syntax, and more)
Note: debian.vim is read from vim81, but no "after" from vim81 is processed.
That's weird. That looks to be an error of the runtimepath.
Notice how that order exactly aligns with the output in :version.
system vimrc file: "$VIM/vimrc"
^-- /usr/share/vim/vimrc, which explicitly loads /etc/vim/vimrc.local
user vimrc file: "$HOME/.vimrc"
^-- ie, /root/.vimrc above
2nd user vimrc file: "~/.vim/vimrc"
^-- ie, /root/.vim/vimrc above
user exrc file: "$HOME/.exrc"
^-- ie, /root/.exec as above,
defaults file: "$VIMRUNTIME/defaults.vim"
^-- as shown, /usr/share/vim/vim81/defaults.vim
fall-back for $VIM: "/usr/share/vim"
output of :se:
display=truncate
helplang=en
history=200
incsearch
langnoremap
nolangremap
nomodeline
mouse=a
nrformats=bin,hex
ruler
scroll=34
scrolloff=5
showcmd
ttimeout
ttimeoutlen=100
ttyfast
ttymouse=xterm
wildmenu
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
printoptions=paper:letter
runtimepath=~/.vim,
/var/lib/vim/addons,
/usr/share/vim/vimfiles,
/usr/share/vim/vim81,
/usr/share/vim/vimfiles/after,
/var/lib/vim/addons/after,~/.vim/after
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
B. As the root user with a .vimrc file:
Output of :se
helplang=en
nomodeline
ruler
scroll=34
ttyfast
ttymouse=xterm
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
printoptions=paper:letter
runtimepath=~/.vim,
/var/lib/vim/addons,
/usr/share/vim/vimfiles,
/usr/share/vim/vim81,
/usr/share/vim/vimfiles/after,
/var/lib/vim/addons/after,
~/.vim/after
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
C. The load order for proposed changes in /etc/vim/debian.vim, root user
without .vimrc:
/usr/share/vim/vimrc
/root/.vim/debian.vim
/etc/vim/debian.vim
/root/.vimrc [if exists: open-noblock, ie, only checked]
/root/.vim/vimrc [if above does not exist and this exists:
open-noblock, ie, only checked]
/usr/share/vim/vim81/defaults.vim
/usr/share/vim/vimfiles/debian.vim
/usr/share/vim/vim81/debian.vim
/usr/share/vim/vimfiles/after/debian.vim
/etc/vim/after/debian.vim
/root/.vim/after/debian.vim
/root/.vimrc
/root/.vim/vimrc
/etc/vim/vimrc.local
Output of :se
display=truncate
helplang=en
history=200
incsearch
langnoremap
nolangremap
nomodeline
mouse=a
nrformats=bin,hex
ruler
scroll=34
scrolloff=5
showcmd
ttimeout
ttimeoutlen=100
ttyfast
ttymouse=xterm
wildmenu
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
printoptions=paper:letter
runtimepath=~/.vim,
/var/lib/vim/addons,
/usr/share/vim/vimfiles,
/usr/share/vim/vim81,
/usr/share/vim/vimfiles/after,
/var/lib/vim/addons/after,~/.vim/after
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
(no difference compared to C)
D. Load order for propose changes in /etc/vim/debian.vim, root user with .vimrc:
/usr/share/vim/vimrc
/root/.vim/debian.vim
/etc/vim/debian.vim
/root/.vimrc [if exists: open-noblock, ie, only checked]
/root/.vim/vimrc [if above does not exist and this exists:
open-noblock, ie, only checked]
/usr/share/vim/vimfiles/debian.vim
/usr/share/vim/vim81/debian.vim
/usr/share/vim/vimfiles/after/debian.vim
/etc/vim/after/debian.vim
/root/.vim/after/debian.vim
/root/.vimrc
/root/.vim/vimrc
/etc/vim/vimrc.local
Output of :se
helplang=en
nomodeline
ruler
scroll=34
ttyfast
ttymouse=xterm
backspace=indent,eol,start
fileencodings=ucs-bom,utf-8,default,latin1
printoptions=paper:letter
runtimepath=~/.vim,
/var/lib/vim/addons,
/usr/share/vim/vimfiles,
/usr/share/vim/vim81,
/usr/share/vim/vimfiles/after,
/var/lib/vim/addons/after,
~/.vim/after
suffixes=.bak,~,.swp,.o,.info,.aux,.log,.dvi,.bbl,.blg,.brf,.cb,.ind,.idx,.ilg,.inx,.out,.toc
(no difference here than with B)
========================================================================
On 220311.., 01:24, "Debian Bug Tracking System" <[email protected]> wrote:
This is an automatic notification regarding your Bug report
which was filed against the vim package:
#1007007: vim: defaults.vim items should not override those in vimrc.local
and home/.vimrc
It has been closed by James McCoy <[email protected]>.
Their explanation is attached below along with your original report.
If this explanation is unsatisfactory and you have not received a
better one in a separate message then please contact James McCoy
<[email protected]> by
replying to this email.
--
1007007: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1007007
Debian Bug Tracking System
Contact [email protected] with problems
