'runtimepath' fiddling

[James Vega]

On Tue, Apr 25, 2006 at 05:56:30PM -0400, Stefano Zacchiroli wrote:
> [ quoted text reordered and took from multiple mails ]
> 
> On Tue, Apr 25, 2006 at 03:13:10PM -0400, James Vega wrote:
> > > However I do see the point of dictating it to something including:
> > > 1) the legacy runtimepath (that which comes with upstream vim)
> > > 2) some paths under /usr/local
> > > 3) some paths under /var
> > My initial thought was to remove any modification of 'runtimepath' since
> > it caused such a hassle when we changed its value in /etc/vim/vimrc.
> > You make some good arguments for reasons to modify it, though.
> 
> So you agree on having both (2) and (3) added to the legacy runtimepath
> in our default setting, don't you?

I see the use in them and now that we're moving our modification of
'runtimepath' outside of places that people would be expected to fiddle
with things, I'd agree we should add them.

> > > I raise an additional issue: we should not set the runtimepath in
> > > /etc/vim/vimrc (a file which is likely to be modified by sysadm)
> > It's probably also a good idea to add more advertising for
> > /etc/vim/{g,}vimrc.local within /etc/vim/vimrc.  That is, instead of
> > saying "uncomment these lines to get this functionality", maybe it would
> > be better to say "add these lines to /etc/vim/vimrc.local" and to add a
> > note at the top of the file stating any modifications should be made in
> > the vimrc.local file.
> 
> I think vimrc.local should not exists.

Currently, it does make sense that it existed, IMO.  Having the sysadmin
make changes to our current /etc/vim/vimrc just increases the chances
that updates we make to the vimrc won't be propagated to our users,
whether intentionally or not.  In some cases that is benign, but the
'runtimepath' change was a prime example of why I like vimrc.local.  Now
that we're moving where our settings are performed, the need for
vimrc.local is negligible.

> On Tue, Apr 25, 2006 at 03:13:10PM -0400, James Vega wrote:
> > Yes, that's probably the best choice.  How does
> > $VIMRUNTIME/debdefaults.vim sound?  Then we would remove the
> > modification of 'runtimepath' from /etc/vim/vimrc and place "runtime
> > debdefaults.vim" after setting 'nocompatible'.
> 
> How about plain $VIMRUNTIME/debian.vim?

Ok.

> I like the idea of 'runtime' in /etc/vim/vimrc so that sysadms can do
> stuff both before and after it.

Doing stuff before the runtime call isn't a good idea since performing
"set nocompatible" may change what they've already set.  Either we leave
that in /etc/vim/vimrc or we stop setting it by default or we put a note
in /etc/vim/vimrc stating that they need to be aware of those effects.

> Still the modifications of 'runtimepath' discussed at the beginning of
> this thread will go in $VIMRUNTIME/debian.vim, have I understood your
> proposal correctly?

Yes.

> On Tue, Apr 25, 2006 at 04:59:30PM -0400, James Vega wrote:
> > In fact, we could just move all of the actual settings in /etc/vim/vimrc
> > to $VIMRUNTIME/debdefaults.vim.  This would leave just the example
> > settings and the runtime call in /etc/vim/vimrc.  Much less chance of
> > conflicts from upgrades.
> 
> Agreed, that would be a good way to remove the need of vimrc.local.
> Still, I expect the sysadms to be able to (selectively) undo everything
> we do in debian.vim. To undo everything it would be enough to comment
> the 'runtime' line and one will get upstream vim settings. Fair enough.
> To undo selectively in theory it should be enough to add a "counter"
> configuration statement after the invocation of 'runtime'. Do you see
> any specific problem with any of the setting we currently have in
> /etc/vim/vimrc?

The one worry I have about this is that people will, again, decide not
to look at the changes being introduced by us and will choose not to
accept our vimrc or merge their changes into it.  Maybe we should add a
NEWS entry explaining the changes and encouraging the sysadmin to
perform the proper action.  This probably would have eased the
transition last time, too.  Oh well, live and learn.

James
-- 
GPG Key: 1024D/61326D40 2003-09-02 James Vega <jamessan at jamessan.com>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: Digital signature
Url : http://lists.alioth.debian.org/pipermail/pkg-vim-maintainers/attachments/20060426/3b227635/attachment.pgp