Re: Proposed bugfix for help
- Bram Moolenaar <Bram@...> wrote:
> Antoine J. Mechelynck wrote:Of course you know Vim better than me. Trying to be complete, I ran the risk
> > Bug: Code examples given in help should in many cases go through
> > all the directories in 'runtimepath' rather than only $VIMRUNTIME.
> > Fix: Replace (where needed) ":source $VIMRUNTIME/" by ":runtime! "
> In many places this is indeed better. But not everywhere.
of excess. In my helpgrep, I skipped many instances where it looked obvious
to me that $VIMRUNTIME/ could stay. Apparently I didn't skip enough of them.
> > *** gui.txt (2004 Apr 02) for Vim 6.2Didn't know that. Somehow I would have expected the opposite.
> > --- 470 ---
> > :source $VIMRUNTIME/menu.vim
> > +++ 470 +++
> > :runtime! menu.vim
> This would suggest Vim reads all menu.vim files, but it doesn't.
> Same remark for other places where menu.vim is used.
> > *** syntax.txt (2004 Mar 26) for Vim 6.2[...]
> > --- 279 ---Then I suppose the reference to 'runtimepath' should fall away. If it hadn't
> > +- Source $VIMRUNTIME/syntax/synload.vim from 'runtimepath'
> > +++ 279 +++
> > +- Source syntax/synload.vim from 'runtimepath'
> Only the file in $VIMRUNTIME is used.
been there I wouldn't have suggested a change at this point.
> > *** usr_01.txt (2003 Jan 12) for Vim 6.2Hm. I beg to differ. I know it will not be easy for me to sway your opinion
> > --- 61-72 ---
> > setup, copy the example vimrc file. By doing this inside Vim you
> > don't have to check out where it is located. How to do this
> > depends on the system you are using:
> > Unix: >
> > :!cp -i $VIMRUNTIME/vimrc_example.vim ~/.vimrc
> > MS-DOS, MS-Windows, OS/2: >
> > :!copy $VIMRUNTIME/vimrc_example.vim $VIM/_vimrc
> > Amiga: >
> > :!copy $VIMRUNTIME/vimrc_example.vim $VIM/.vimrc
> > If the file already exists you probably want to keep it.
> > +++ 61-66 +++
> > setup, include the example vimrc file. An easy way to do this is to
> > have the line: >
> > runtime vimrc_example.vim
> > near the start of your vimrc. Place your own preferences after
> > that, so they override the defaults, and not vice-versa.
> I prefer users to make a copy and modify it. It's an example, not
> something you would include and then overrule. That is too
> for beginners.
in such a matter. Let me try though.
In my approach (sourcing rather than copying) I see several advantages:
(a) The newbie doesn't need to open a long and complex file, nor to try to
understand it, in order to set his own preferences. Let's face it: the
vimrc_example.vim is not something easy to understand, much less to modify
sensibly, for someone who has just "taken the plunge" into Vim. (The first
time I opened the _vimrc which [IIRC] the install process had created by
copying the vimrc_example.vim, it gave me a headache. So, rather than modify
something I didn't understand, I added one "source" command at the very
bottom to source my own preferences -- the above process in reverse. Later I
came to see that sourcing the original, unchanged vimrc_example.vim near the
start of a user vimrc was both simpler and safer, just as easy for the
newbie, and allowed placing a few specific commands like ":language messages
en" before the code in the vimrc_example.vim if they appeared not to work
(b) I'm not stuck with a "frozen" version of the vimrc_example.vim. Any bugs
in it will be corrected by the next upgrade after they are found, with no
user intervention (other than applying the upgrade of course) and with no
corruption of any user's preferences.
(c) It divides the responsibilities more neatly: Bram writes and maintains
the vimrc_example.vim. I may accept, or not, any of its choices (as well as
any of Vim's builtin defaults), but I do so by writing down my own choices
at a different place (in my user vimrc). For anything I don't know or care
about, I rely on Bram's choices, at least until I know better.
Another possibility (possibly even better, but I hadn't thought of it before
today) would be to copy the vimrc_example.vim to $VIM/vimrc (or source it
from there) while placing user preferences in ~/.vimrc (or, on Windows, but
in Vim parlance, in $HOME/_vimrc or $VIM/_vimrc). Thus the vimrc_example.vim
would serve as "system default" (upon which, on a multi-user system, a
competent sysadmin could build) while the user (newbie or otherwise) would
start adding his own preferences to a "user" vimrc, which would start small
and simple, and grow at the rhythm of the user's expertise.
I think we both agree that the vimrc_example.vim is a good "general purpose"
vimrc, a very good starting point for almost everyone: for most people it is
"almost, but not quite" what they want. IMHO this implies that it makes
sense to change a few of its settings, in an easily identifiable and
> --Best regards,
> hundred-and-one symptoms of being an internet addict:
> 87. Everyone you know asks why your phone line is always busy ...and
> you tell them to send an e-mail.
> /// Bram Moolenaar -- Bram@... -- http://www.Moolenaar.net
> \\\ /// Sponsor Vim, vote for features --
> http://www.Vim.org/sponsor/ \\\ \\\ Project leader for
> A-A-P -- http://www.A-A-P.org /// \\\ Buy at Amazon and help
> AIDS victims -- http://ICCF.nl/click1.html ///