Re: splitting $HOME/.vimrc
From: A.J.Mechelynck [EMAIL PROTECTED] Subject: Re: splitting $HOME/.vimrc Date: Fri, 29 Sep 2006 07:26:33 +0200 Meino Christian Cramer wrote: [...] By the way: I am using Linux. Since kernel 1.1.54 my room has no windows anymore ;) Keep hacking! mcc Not even X-windows? Best regards, Tony. ohmy fault! I forget to add (tm) ! :O) More seriously: May be that I got an [OK][CANCEL]-allergy... ;) Means: I am using IceWM as windowmanager only. For me KDE/GNOME are too big -- this does not mean, that GNOME/KDE are _bad_ ... they only dont fit my needs. I use the windowmanager mostly for haveing more terminals with more lines of text and more rows on more desktops with a more conveniently way to switch from one to another. And yes, I am using things like k3b or digikam (and have therefore a rudimentary KDE/GNOME installed -- just to be able to compile a few of their applikations...). But mainly I like text based UIs more than heavily graphic based UIs. May be that is based on the faxt that I can read better than draw?! Dont know I feel, that the mapping the possibilities of an computer onto the simplicity of an [OK][CANCEL]-based world is a limititation I dont want to accept for me. This is not identical to the acceptance of unreadable manuals/help texts, which do mention everything at places no one can find without reading the complete text! Read the source, Luke may be an intellectual approach rhetorical-wise but do not help really. Only my two cents...your mileage may vary... Keep hacking! mcc
Re: splitting $HOME/.vimrc
Meino Christian Cramer wrote: [...] I feel, that the mapping the possibilities of an computer onto the simplicity of an [OK][CANCEL]-based world is a limititation I dont want to accept for me. This is not identical to the acceptance of unreadable manuals/help texts, which do mention everything at places no one can find without reading the complete text! Read the source, Luke may be an intellectual approach rhetorical-wise but do not help really. Only my two cents...your mileage may vary... Keep hacking! mcc At least, the Vim help not only mentions everything, but there are tools to find your needle in the haystack without overturning the latter straw by straw. For instance, helptag completion (type :help pattern then hit Tab, especially after setting 'wildmenu') and the :helpgrep command. Best regards, Tony.
Re: splitting $HOME/.vimrc
you can run normal commands with
:normal
for example,
:normal dd
will delete a whole line
On Friday 29 September 2006 11:22, Meino Christian Cramer wrote:
From: A.J.Mechelynck [EMAIL PROTECTED]
Subject: Re: splitting $HOME/.vimrc
Date: Fri, 29 Sep 2006 05:04:30 +0200
Meino Christian Cramer wrote:
Hi,
for my zsh I split the .zshrc in several files, which contain only
related things. For example all bindkey-related things go into
.zsh.bindkey.
.zshrc only sources those parts if available. Make things more
readable.
I would like to do the same thing with my $HOME/.vimrc.
I looked into
:he source
but source seems to work for ex commands only, or ?
Is there a way, to source several files as startup files from
within $HOME/.vimrc, without a too great performance penalty on
startup time ?
Keep hacking!
mcc
Your vimrc is supposed to consist of ex-commands only (ex-commands are
the commands you can type in Normal mode by prefixing them with a colon;
in a script such as the vimrc, the colon is not necessary). So you should
be able to dissect your vimrc into, let's say,
if has('unix')
language messages C
else
language messages en
endif
runtime vimrc_example.vim
source ~/rc1.vim
source ~/rc2.vim
source ~/rc3.vim
An alternative would be to create user-plugins, scripts which you would
place in ~/.vim/plugin/ (for Unix) or ~/vimfiles/plugin/ (for Windows).
They would then be sourced automagically in (probably) alphabetical
order, just before the global plugins (i.e., after your ~/.vimrc): see
the output of the :scriptnames command.
(and if you don't yet have the required directory, create it with:
on Linux:
mkdir -p ~/.vim/plugin
on Windows:
cd %HOME%
md vimfiles
cd vimfiles
md plugin
Best regards,
Tony.
Hi Tony, :)
thank you for your helpful reply !
Initially I thought, ex-commands were only a small subset of all
commands, which can be used after :.
But...
If _all_ commands, which are valid after :, are ex-commands...the
situation is quite simple.
By the way: I am using Linux. Since kernel 1.1.54 my room has no
windows anymore ;)
Keep hacking!
mcc
--
[EMAIL PROTECTED]
splitting $HOME/.vimrc
Hi, for my zsh I split the .zshrc in several files, which contain only related things. For example all bindkey-related things go into .zsh.bindkey. .zshrc only sources those parts if available. Make things more readable. I would like to do the same thing with my $HOME/.vimrc. I looked into :he source but source seems to work for ex commands only, or ? Is there a way, to source several files as startup files from within $HOME/.vimrc, without a too great performance penalty on startup time ? Keep hacking! mcc
Re: splitting $HOME/.vimrc
Meino Christian Cramer wrote:
Hi,
for my zsh I split the .zshrc in several files, which contain only
related things. For example all bindkey-related things go into
.zsh.bindkey.
.zshrc only sources those parts if available. Make things more
readable.
I would like to do the same thing with my $HOME/.vimrc.
I looked into
:he source
but source seems to work for ex commands only, or ?
Is there a way, to source several files as startup files from
within $HOME/.vimrc, without a too great performance penalty on
startup time ?
Keep hacking!
mcc
Your vimrc is supposed to consist of ex-commands only (ex-commands are the
commands you can type in Normal mode by prefixing them with a colon; in a
script such as the vimrc, the colon is not necessary). So you should be able
to dissect your vimrc into, let's say,
if has('unix')
language messages C
else
language messages en
endif
runtime vimrc_example.vim
source ~/rc1.vim
source ~/rc2.vim
source ~/rc3.vim
An alternative would be to create user-plugins, scripts which you would
place in ~/.vim/plugin/ (for Unix) or ~/vimfiles/plugin/ (for Windows). They
would then be sourced automagically in (probably) alphabetical order, just
before the global plugins (i.e., after your ~/.vimrc): see the output of the
:scriptnames command.
(and if you don't yet have the required directory, create it with:
on Linux:
mkdir -p ~/.vim/plugin
on Windows:
cd %HOME%
md vimfiles
cd vimfiles
md plugin
Best regards,
Tony.
Re: splitting $HOME/.vimrc
From: A.J.Mechelynck [EMAIL PROTECTED]
Subject: Re: splitting $HOME/.vimrc
Date: Fri, 29 Sep 2006 05:04:30 +0200
Meino Christian Cramer wrote:
Hi,
for my zsh I split the .zshrc in several files, which contain only
related things. For example all bindkey-related things go into
.zsh.bindkey.
.zshrc only sources those parts if available. Make things more
readable.
I would like to do the same thing with my $HOME/.vimrc.
I looked into
:he source
but source seems to work for ex commands only, or ?
Is there a way, to source several files as startup files from
within $HOME/.vimrc, without a too great performance penalty on
startup time ?
Keep hacking!
mcc
Your vimrc is supposed to consist of ex-commands only (ex-commands are the
commands you can type in Normal mode by prefixing them with a colon; in a
script such as the vimrc, the colon is not necessary). So you should be able
to dissect your vimrc into, let's say,
if has('unix')
language messages C
else
language messages en
endif
runtime vimrc_example.vim
source ~/rc1.vim
source ~/rc2.vim
source ~/rc3.vim
An alternative would be to create user-plugins, scripts which you would
place in ~/.vim/plugin/ (for Unix) or ~/vimfiles/plugin/ (for Windows). They
would then be sourced automagically in (probably) alphabetical order, just
before the global plugins (i.e., after your ~/.vimrc): see the output of the
:scriptnames command.
(and if you don't yet have the required directory, create it with:
on Linux:
mkdir -p ~/.vim/plugin
on Windows:
cd %HOME%
md vimfiles
cd vimfiles
md plugin
Best regards,
Tony.
Hi Tony, :)
thank you for your helpful reply !
Initially I thought, ex-commands were only a small subset of all
commands, which can be used after :.
But...
If _all_ commands, which are valid after :, are ex-commands...the situation
is
quite simple.
By the way: I am using Linux. Since kernel 1.1.54 my room has no
windows anymore ;)
Keep hacking!
mcc
