New version of vim unsolicitedly sourcing defaults.vim?

[Tim Chase]

I upgraded packages on my FreeBSD box yesterday and noticed that
vimrc behavior had changed.

Prior to the upgrade, if I had a ~/.vimrc it wouldn't source the
defaults.vim file.

:help VIMINIT

> The first that exists is used, the others are ignored.

and it proceeds to list .vimrc (which I have) and, later down,
defaults.vim (which should be ignored because I have a .vimrc)

However, 'scrolloff' and 'mouse' are now annoyingly getting set
(along with other defaults.vim tweaks):

:verbose set scrolloff? mouse?
mouse=nvi
Last set from /usr/local/share/vim/vim90/defaults.vim line 85
scrolloff=5
Last set from /usr/local/share/vim/vim90/defaults.vim line 51

According to tracing startup:

:scriptnames
1: /usr/local/etc/vim/vimrc
2: /usr/local/share/vim/vim90/defaults.vim
3: /usr/local/share/vim/vim90/filetype.vim
4: /usr/local/share/vim/vim90/ftplugin.vim
5: /usr/local/share/vim/vim90/indent.vim
6: /usr/local/share/vim/vim90/syntax/syntax.vim
7: /usr/local/share/vim/vim90/syntax/synload.vim
8: /usr/local/share/vim/vim90/syntax/syncolor.vim
9: /usr/local/share/vim/vim90/colors/lists/default.vim
10: /usr/local/share/vim/vim90/syntax/nosyntax.vim
11: ~/.vimrc
[snip]

it's the /usr/local/etc/vim/vimrc causing the issue.

Is this a FreeBSD package customization problem (and I should go
grumble to the FreeBSD package maintainer(s)), or did the default
system vimrc start ignoring the description in `:help VIMINIT`, and
force defaults.vim on those of us who detest it (in which case,
please revert this)?

-Tim



:ver
VIM - Vi IMproved 9.0 (2022 Jun 28, compiled Jul 5 2022 15:41:14)
Included patches: 1-16
Compiled by root@130amd64-quarterly-job-15
Huge version without GUI. Features included (+) or not (-):
+acl +file_in_path +mouse_urxvt -tag_any_white
+arabic +find_in_path +mouse_xterm -tcl
+autocmd +float +multi_byte +termguicolors
+autochdir +folding +multi_lang +terminal
-autoservername -footer -mzscheme +terminfo
-balloon_eval +fork() +netbeans_intg +termresponse
+balloon_eval_term +gettext +num64 +textobjects
-browse -hangul_input +packages +textprop
++builtin_terms +iconv +path_extra +timers
+byte_offset +insert_expand -perl +title
+channel +ipv6 +persistent_undo -toolbar
+cindent +job +popupwin +user_commands
+clientserver +jumplist +postscript +vartabs
+clipboard +keymap +printer +vertsplit
+cmdline_compl +lambda +profile +vim9script
+cmdline_hist +langmap -python +viminfo
+cmdline_info +libcall +python3 +virtualedit
+comments +linebreak +quickfix +visual
+conceal +lispindent +reltime +visualextra
+cryptv +listcmds +rightleft +vreplace
+cscope +localmap -ruby +wildignore
+cursorbind -lua +scrollbind +wildmenu
+cursorshape +menu +signs +windows
+dialog_con +mksession +smartindent +writebackup
+diff +modify_fname -sodium +X11
+digraphs +mouse -sound +xfontset
-dnd -mouseshape +spell -xim
-ebcdic +mouse_dec +startuptime -xpm
+emacs_tags -mouse_gpm +statusline +xsmp_interact
+eval -mouse_jsbterm -sun_workshop +xterm_clipboard
+ex_extra +mouse_netterm +syntax -xterm_save
+extra_search +mouse_sgr +tag_binary
-farsi +mouse_sysmouse -tag_old_static
system vimrc file: "/usr/local/etc/vim/vimrc"
user vimrc file: "$HOME/.vimrc"
2nd user vimrc file: "~/.vim/vimrc"
user exrc file: "$HOME/.exrc"
defaults file: "$VIMRUNTIME/defaults.vim"
fall-back for $VIM: "/usr/local/etc/vim"
f-b for $VIMRUNTIME: "/usr/local/share/vim/vim90"
Compilation: cc -c -I. -Iproto -DHAVE_CONFIG_H -DLIBICONV_PLUG -I/usr/local/incl
ude -O2 -pipe -DLIBICONV_PLUG -fstack-protector-strong -fno-strict-aliasing -D_R
EENTRANT -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -I/usr/local/include
Linking: cc -L/usr/local/lib -fstack-protector-strong -L/usr/local/lib -Wl,--as-
needed -o vim -lSM -lICE -lXpm -lXt -lX11 -lXdmcp -lSM -lICE -lm -lelf -pthread
-lncursesw -lrt -lintl -L/usr/local/lib/python3.9/config-3.9 -lpython3.9 -lcrypt
-lintl -ldl -L/usr/local/lib -lintl -lutil -lm -lm

[Bram Moolenaar]

Vim does not include a system-wide vimrc file that would go in
/usr/local/etc/vim. Does this file source defaults.vim? Then that's a
problem of FreeBSD.

--
Microsoft: "Windows NT 4.0 now has the same user-interface as Windows 95"
Windows 95: "Press CTRL-ALT-DEL to reboot"
Windows NT 4.0: "Press CTRL-ALT-DEL to login"

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// \\\
\\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Yegappan Lakshmanan]

Hi,

The following FreeBSD bug may be relevant to this:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251420

- Yegappan

[Tim Chase]

On Tue, Aug 09, 2022 at 10:06:37PM +0100, Bram Moolenaar wrote:
> Vim does not include a system-wide vimrc file that would go in
> /usr/local/etc/vim. Does this file source defaults.vim?

Yes, this file sources defaults.vim

I was unsure of its provenance, but with your confirmation that
it's not part of vim-proper's installation, it looks like a FreeBSD
thing:

> Then that's a problem of FreeBSD.

Yep, as Yegappan found, this bug is tracking the issue at hand:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251420

I've got a FreeBSD Bugzilla account and will follow up there.

Thanks!

-tim

[Bram Moolenaar]

It should be made clear to them that the basic idea behind defaults.vim
is to set nicer defaults for new users. Existing users, who have a
~/.vimrc with their preferences, should not get defaults.vim
automatically.

Since /usr/local/etc/vi/vimrc appears to intend to set some system-wide
preferences, which might be overruled by defaults.vim if the user
doesn't have a .vimrc file, they have been struggling with this. They
probably want to disable loading defaults.vim and set their own
preferences. Bad luck for new users, they will have to figure out their
own settings. And they will keep discussing forever what the defaults
for everybody on the system should be.

An alternative would be to check if ~/.vimrc exists, and only load
defaults.vim then. Then it's closer to what Vim normally does (but then
the overrides may still confuse the user).

--
He was not in the least bit scared to be mashed into a pulp
Or to have his eyes gouged out and his elbows broken;
To have his kneecaps split and his body burned away
And his limbs all hacked and mangled, brave Sir Robin.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

[Tim Chase]

On Wed, Aug 10, 2022 at 11:07:55AM +0100, Bram Moolenaar wrote:
>Tim Chase wrote:
>> Yep, as Yegappan found, this bug is tracking the issue at hand:
>>
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=251420
>>
>> I've got a FreeBSD Bugzilla account and will follow up there.

[snip]

> An alternative would be to check if ~/.vimrc exists, and only load
> defaults.vim then. Then it's closer to what Vim normally does (but then
> the overrides may still confuse the user).

That's one of the solutions I proposed in that bug-tracking URL,
though it's complicated because it's not just a .vimrc but according
to docs, but it sounds like ~/.vim/vimrc or ~/_vimrc or ~/.exrc or
~/_exrc or $MYVIMRC or $VIMINIT or $VIM or $EXINIT might also prevent
defaults.vim from loading. And I'm not 100% certain that list is
complete.

So it sounds like it would require a big chained if-statement testing
filereadable() on all of those sources and only sourcing defaults.vim
if *none* of them exist.

-tim

[N V]

Hi Tim, Bram,

In a "gradient minimalist" mode of vim, devoid of plugins, it might be interesting to have a file that contains the necessary facilities by default. In particular facilities, features allowing you to switch from this minimalist Vim mode to a more extensive mode including personal plugins and other functions...

As long as the defaults.vim file is in the same folder as $MYVIMRC, is the defaults.vim file sourced on Vim startup?

I personally need this functionnality :

in Vim minimalist  "degraded"    mode   :    defaults.vim  is the only  in $vim                    so facilities it is embedding are sourced

in Vim extended    "operational"  mode  :    both defaults.vim and _vimrc are in $vim,    so facilities _vimrc is embedding are sourced.

Is it possible Bram ?

Thank you

Nicolas

[Tony Mechelynck]

Yes, it's your distro admins giving you what they think is good for
you. That's the problem with Vim executables built by distro
maintainers: they often come with a "system vimrc" doing undesired
things. If you compile your own Vim with default directory settings,
it will look for a system vimrc at /usr/local/share/vim/vimrc, find
none, and happily proceed with your ~/.vimrc (which, in my own-built
Vim, comes at the very top of the :scriptnames). What I do near (but
not at) the top of my ~/.vimrc is source the
$VIMRUNTIME/vimrc_example.vim (which, in recent versions of Vim,
sources the defaults.vim) and then undo whatever it sets that I don't
like (e.g. I have a line "filetype indent off" to counteract the
"indent" part of its "filetype plugin indent on").

Best regards,
Tony.

[Tim Chase]

On Thu, Aug 11, 2022 at 11:31:22AM +0200, Tony Mechelynck wrote:
>On Tue, Aug 9, 2022 at 7:54 PM Tim Chase <v...@tim.thechases.com> wrote:
>>
>> I upgraded packages on my FreeBSD box yesterday and noticed that
>> vimrc behavior had changed.

[snip]
>> :scriptnames

>
> Yes, it's your distro admins giving you what they think is good for
> you.

that matches our conclusions (see the ticket on the FreeBSD bug-tracker)

> What I do near (but not at) the top of my ~/.vimrc is source the
> $VIMRUNTIME/vimrc_example.vim (which, in recent versions of Vim,
> sources the defaults.vim) and then undo whatever it sets that I don't
> like

I don't want to have to keep up with whatever new settings get put
in defaults.vim, undoing them back to what I want (i.e., what they
were before this whole defaults.vim thing). I feel vim did the
right thing with the "if they have a vimrc, don't source defaults.vim".
As detailed at that ticket, I believe the best solution is for
FreeBSD to not have a system vimrc that sources defaults.vim
unconditionally, but rather to have their ports process patch the
defaults.vim to contain the couple extra helper bits they want.

-tim

[Tony Mechelynck]

On Thu, Aug 11, 2022 at 3:18 PM Tim Chase <v...@tim.thechases.com> wrote:
>
> On Thu, Aug 11, 2022 at 11:31:22AM +0200, Tony Mechelynck wrote:
> >On Tue, Aug 9, 2022 at 7:54 PM Tim Chase <v...@tim.thechases.com> wrote:
> >>
> >> I upgraded packages on my FreeBSD box yesterday and noticed that
> >> vimrc behavior had changed.
> [snip]
> >> :scriptnames
> >
> > Yes, it's your distro admins giving you what they think is good for
> > you.
>
> that matches our conclusions (see the ticket on the FreeBSD bug-tracker)
>
> > What I do near (but not at) the top of my ~/.vimrc is source the
> > $VIMRUNTIME/vimrc_example.vim (which, in recent versions of Vim,
> > sources the defaults.vim) and then undo whatever it sets that I don't
> > like
>
> I don't want to have to keep up with whatever new settings get put
> in defaults.vim, undoing them back to what I want (i.e., what they
> were before this whole defaults.vim thing). I feel vim did the
> right thing with the "if they have a vimrc, don't source defaults.vim".

That's your choice, and it's a sensible one.

Long before defaults.vim existed, I decided that the vimrc_example.vim
did _almost_ what I wanted, so I sourced it then undid the very few
settings which were not what I liked. There weren't many, so that
works for me. YMMV.

> As detailed at that ticket, I believe the best solution is for
> FreeBSD to not have a system vimrc that sources defaults.vim
> unconditionally, but rather to have their ports process patch the
> defaults.vim to contain the couple extra helper bits they want.
>
> -tim

I believe that Vim has a good set of defaults, including (in recent
versions) sourcing defaults.vim when no user vimrc was found (if you
have a vimrc, and still want the settings of the defaults.vim, or most
of them like I do, well, just source it), so a system vimrc is almost
never necessary, or even useful.

I don't think a distro should patch the defaults.vim, or any other Vim
source file for that matter. Vim is good enough as it stands, and if a
bug is found in it, then IMHO a distro maintainer ought to report the
bug (and any fix or workaround they found) to Bram (or, in the case of
a plugin, to the plugin maintainer), just like any user can, so that
(a) all Vim users, and not only those of that particular distro, can
profit from the bugfix; (b) at least one additional pair of eyes
(Bram's) will have a look at the proposed fix before it becames part
of Vim; and (c) if that proposed fix prevents Vim from building, even
on some different platform, someone will find that out really fast.

Forking Vim is possible and the license allows it; but once some
distro does it, they'll have to import into their fork any new
enhancements brought into the Vim source, or that fork will fall
behind fast; and OTOH any changes relative to the "official" Vim must
be made available to Bram gratis on request, letting him use them in
the official source without restriction if (and only if) he wants to.

Best regards,
Tony.

[Tim Chase]

On Fri, Aug 12, 2022 at 12:29:24AM +0200, Tony Mechelynck wrote:
> I believe that Vim has a good set of defaults, including (in recent
> versions) sourcing defaults.vim when no user vimrc was found (if you
> have a vimrc, and still want the settings of the defaults.vim, or most
> of them like I do, well, just source it), so a system vimrc is almost
> never necessary, or even useful.

The other settings in defaults.vim don't usually give me much grief, but
having a non-0 'scrolloff' means my usual

{count}H
{count}L

no longer land {count} lines from the top/bottom of the screen,
but rather {count} + &scrolloff lines from the top/bottom.

Additionally a non-empty 'mouse' setting means that my usual "select
some text with the mouse (like I do in every other terminal situation)
and let my xterm/rxvt put it in the X selection buffer" stops
working.

> I don't think a distro should patch the defaults.vim, or any other Vim
> source file for that matter. Vim is good enough as it stands, and if a

Of the two items I found valuable in the FreeBSD tweaks, one was

let g:is_posix = 1 " Our /bin/sh is POSIX, not bash

as detailed at `:help ft-posix-syntax`. It also sounded reasonable
to have a BufNewFile read in a template when creating a new file
under the ports tree, but it feels like this would be better
instituted in some ft-detection section of things rather than in
defaults.vim

> Forking Vim is possible and the license allows it

In this case, it's less of a fork and more of a light patching/tweak
atop the stock distro, allowing it to more easily track the vim
upstream, but this particular change caused unfortunate side-effects.

-tim

[Christian Brabandt]

On Fr, 12 Aug 2022, Tim Chase wrote:

> On Fri, Aug 12, 2022 at 12:29:24AM +0200, Tony Mechelynck wrote:
> > I believe that Vim has a good set of defaults, including (in recent
> > versions) sourcing defaults.vim when no user vimrc was found (if you
> > have a vimrc, and still want the settings of the defaults.vim, or most
> > of them like I do, well, just source it), so a system vimrc is almost
> > never necessary, or even useful.
>
> The other settings in defaults.vim don't usually give me much grief, but
> having a non-0 'scrolloff' means my usual
>
> {count}H
> {count}L
>
> no longer land {count} lines from the top/bottom of the screen,
> but rather {count} + &scrolloff lines from the top/bottom.

The 'scrolloff' setting is also my major issue with defaults.vim and it
makes copy/pasting with a mouse from a terminal so much more harder.

Sometimes I find it useful when searching and I need the context, but
when I do, setting it explicitly is good enough.

> Additionally a non-empty 'mouse' setting means that my usual "select
> some text with the mouse (like I do in every other terminal situation)
> and let my xterm/rxvt put it in the X selection buffer" stops
> working.

Funnily enough, the mouse setting does not hurt me as much as expected.

Hm actually it looks like most distributions that I have to jump on (
which are usually enterprise distros), either use the same source
package or all of them patch out setting the mouse in defaults.vim

> > Forking Vim is possible and the license allows it
>
> In this case, it's less of a fork and more of a light patching/tweak
> atop the stock distro, allowing it to more easily track the vim
> upstream, but this particular change caused unfortunate side-effects.

In my opinion, forks just create too much of hate in the community.

Best,
Christian
--
Kleiner Schmerz ist in Augenblicken leidlich, aber nicht in der
Fortdauer; also liegt die Ursache unserer Ungeduld darin, daß er uns
immer unterbricht.
-- Jean Paul

[Gary Johnson]

On 2022-08-12, Christian Brabandt wrote:
> On Fr, 12 Aug 2022, Tim Chase wrote:

> > The other settings in defaults.vim don't usually give me much grief, but
> > having a non-0 'scrolloff' means my usual
> >
> > {count}H
> > {count}L
> >
> > no longer land {count} lines from the top/bottom of the screen,
> > but rather {count} + &scrolloff lines from the top/bottom.
>
> The 'scrolloff' setting is also my major issue with defaults.vim and it
> makes copy/pasting with a mouse from a terminal so much more harder.
>
> Sometimes I find it useful when searching and I need the context, but
> when I do, setting it explicitly is good enough.

I also want to move the cursor anywhere on the screen while also
wanting some context around search hits. I have this mapping and
function in my vimrc which enables 'scrolloff' briefly at the end
of n and N commands.

nnoremap <silent> n :call ScrolloffCmd('nzv')<cr>
nnoremap <silent> N :call ScrolloffCmd('Nzv')<cr>
function! ScrolloffCmd(cmd)
try
exe 'normal!' a:cmd
catch
echohl ErrorMsg
echomsg matchstr(v:exception, ':\zs.*')
echohl NONE
endtry
let l:scrolloff = &scrolloff
set scrolloff=2
redraw
let &scrolloff = l:scrolloff
endfunction

I've done similar corrections for tag jumps and quickfix jumps.
That doesn't cover every case where it would be nice to have context
following a jump, but it covers the most annoying ones.

Regards,
Gary