Hi Tony :)
* A.J.Mechelynck <[EMAIL PROTECTED]> dixit:
> >DervishD wrote:
> > I don't want such cluttering, either. My idea is to have the
> >following:
> >
> > - A 'vimrc' that just sources 'modules' (right now my vimrc does
> >little except sourcing 'options.vim', 'mappings.vim' and a couple more
> >things).
> >
> > - The framework for filetypes, ftplugins, syntax highlighting and
> >indentation.
> >
> > - Filetypes. This is the most important part. My idea is having
> >something like "c_f.vim" "c_s.vim" and "c_i.vim" for the "c" filetype,
> >containing ftplugin things, syntax things and indentation things,
> >instead of having "ftplugin/c.vim", "syntax/c.vim" and "indent/c.vim". I
> >haven't decided if I will put the "c_?.vim" files under /etc/vim or in
> >a subdir. For me is much more comfortable to manage all this if the
> >three files are in the same directory and not in three separate subdirs.
> >
>
> What about leaving the files where they are, and also do (in the shell)
>
> cd ~/.vim/after/ftplugin
> ln -sv ../../c_f.vim c.vim
> cd ../syntax
> ln -sv ../../c_s.vim c.vim
> cd ../indent
> ln -sv ../../c_i.vim c.vim
>
> Then you can edit the files in ~/.vim, and Vim will find them "as if they
> were" in their respective after-directories.
Yes, that's an option, but I prefer to build a new scheme instead of
using "/after" and symlinks. It's much easier for me if the entire
structure is in my head instead of having to take into account the
existing runtime *and* my changes in "/after".
> ...and, why reinvent the wheel when the source is open?
First, for fun. Second, because being the source open I can
investigate, learn and do a good job. Third, for the same reason I've
written my own window manager, my own sysvinit replacement, my own
syslogd replacement, my own system for building software, etc. :just
because I like it and I can. I have the urge of doing this kind of
things ;))
> If I were you, I would study the existing runtime files but not change
> them in-place. If you try to re-create everything from the ground up,
> you're bound to introduce bugs (Errare humanum est).
Yes, I know, but I don't mind to take the risk. Moreover, by keeping
the runtime simple, the chance for errors is minor. In addition to this,
the default runtime has bugs or at least weird behaviours. For example,
the keyword "mapclear" in vim scripts is not highlighted properly, and
"source"d files are highlighted, so if you do "source perl.vim", the
"perl" word is highlighted as a keyword. The problem is that I'm not
sure if this is a bug or some strange interaction between my options
settings and the runtime syntax file, that's very difficult to spot and
difficult to investigate.
> OTOH, if by studying the existing scripts you _find_ bugs, then after
> making sure of your facts you could send a patch to the maintainer.
That's a good reason to keep things as they are, but while I write
my own runtime I will test thoroughly the default one and may spot some
bug.
I think I'll take the risk and of course I'll try my best not to
bother the list with my self-induced problems in doing so O:)) Again,
thanks :)
Raúl Núñez de Arenas Coronado
--
Linux Registered User 88736 | http://www.dervishd.net
It's my PC and I'll cry if I want to... RAmen!
