On 28/09/11 13:19, Dwayne Henderson wrote:
Hello!
Whenever I install gVim on a new machine, I'm frustrated by the way
its configuration is scattered throughout different files and folders,
seeing there's a lot of default annoyances I need to disable, plus
some stuff I need to add myself.
In "C:\Program Files (x86)\Vim", there's _vimrc. In "C:\Program Files
(x86)\Vim\vim73" there's gvimrc_example.vim and vimrc_example.vim, not
to mention all the other obscurely named .vim files in the same
folder. Can't it all just be in the same file?
--Dwayne
The example files are only that - examples. They are not used unless
your own vimrc or gvimrc sources them, and whether or not they do, it's
your choice.
You may have a separate gvimrc, or a section of your vimrc between ":if
has('gui_running')" and ":endif", or even a GUIEnter autocommand. Or if
you never use gvim, you don't need any of that.
The global plugins are separate files because they are self-contained
units, which are normally regarded as enhancements to the basic function
of Vim, but you can disable them one at a time (by setting an
appropriate variable to make the plugin believe that it has already been
sourced) or all together (by starting Vim with --noplugin).
Other runtime files are segregated by function (filetype plugins, syntax
scripts, indent scripts, autoload scripts, color schemes, keymaps, spell
checking scripts, etc.) plus a few "utility" scripts living at top level
in $VIMRUNTIME. These scripts are not all maintained by the same person.
If there were only one huge configuration script instead of all those
distinct scripts, the Vim runtime script would be much more like
spaghetti code, much less easy to maintain, and therefore much more
bug-prone.
And the fact that the scripts distributed with Vim are *not* the same as
your own vimrc is IMHO a very important advantage: it allows you to
write your own customizations and to be sure that they won't be altered
on upgrade, while it also allows the scripts distributed with Vim to be
updated easily and cleanly when necessary, without any bit-rot from your
own customizations.
Best regards,
Tony.
--
Never make anything simple and efficient when a way can be found to
make it complex and wonderful.
--
You received this message from the "vim_dev" 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