On Thu, Aug 11, 2022 at 3:18 PM Tim Chase <vim@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 <vim@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.
--
--
You received this message from the "vim_use" 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_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vim_use+unsubscribe@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/vim_use/CAJkCKXv88cuSWGC4uP-EjdG%3DH4SUa%3Dc0uaHabqX8umMw7YcU-Q%40mail.gmail.com.
No comments:
Post a Comment