Hi Bram :)
* Bram Moolenaar <[EMAIL PROTECTED]> dixit:
> DervishD wrote:
>
> > Don't take me wrong: I'm not critisizing Bram's amazing work with
> > Vim, and I'm not asking for this to be "fixed". What I really mean is
> > that Vim will be more flexible if it doesn't have that hardcoded paths
> > and that I'm ready to prepare patches to modify this, one dir per patch,
> > if Bram will accept them.
> >
> > So, Bram, if you could tell me where the limits are for the patches
> > you will accept, or if you could tell me a good reason for not doing
> > this (and "I don't want this done" is a perfectly good reason for me,
> > Vim is yours and not mine, and it's good enough for me as it is), I will
> > prepare as many patches as needed to fix this situation, at least for
> > things like documentation, the runtime subdirs can be fixed after that.
>
> I recommend putting the files below the $VIMRUNTIME directory. Thus
> keep all Vim runtime files together. I don't see how this can break any
> recommendation. How can the LSB define something that goes against how
> Vim uses subdirectories in $VIMRUNTIME?
This is not about policy, under LSB all vim files fit together under
/usr/share/lib/vim, for example. That's not the point. In fact, even
considering that help files are documentation (and you've stated clearly
that they are not, in other message), a simple symlink will do the job
for tools that handle documentation automatically.
I mean, that's not the point. The point is that the source code is
using hardcoded directories, and that is not a good practice, even if
you force to have all runtime files under the same directory, because
someone could change one of the many variables under "src/Makefile" and
have the files installed in a place where the source code (which doesn't
use those variables) won't be able to find them.
> If you really want to do it differently you are on your own. It's
> good that this is difficult, so that people who are causing problems
> for users will have to work hard to do that.
I don't see how getting rid of hardcoded directories in the source
code is going to cause problems for users ;) In fact, hardcoded
directories may cause problems: if you modify "src/Makefile" and don't
reflect those changes in the source, for example. Of course, end users
shouldn't modify things under "src/Makefile" if they're marked as "DON'T
MODIFY THIS", but they don't have to work hard to do that and it will
cause problems.
If you don't want the hardcoded dirs removed (and that's your
design, so I respect that), then how about getting rid of variables in
the "*SUBDIR" and "*SUBLOC" families? This way is not hard, but
IMPOSSIBLE to break things even using the hardcoded directories :)
The change is amazingly simple and makes sense: SUBDIR variables are
only used by SUBLOC variables, and those in turn are only used in the
DEST_ variables, which make use of DESTDIR. A simple substitution will
avoid risks and then users will *really* have to work harder to break
things. And that includes annoying users like me ;)))
I think this is a good idea (much less intrusive than that of
modifying the source code) but hey, I'm not going to argue with you
because I *really* love vim like it is now and I consider your work an
amazing piece of code: elegant, easy to follow and does its job
amazingly good. I'm not licking your arse ;), it's really what I think
of vim. Consider the issue just a suggestion from a fan ;)
Again, thanks for your answer and for taking the time :)
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!
