DervishD wrote:

>     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.

OK, so we should remove the variables from Makefile, so that nobody is
tempted to change them.

It's mostly OK to hardcode the directory names in the source code, since
they can't be changed without causing lots of trouble.  Of course it
would be nicer to put them together somewhere, but since C doesn't
support string concatenation this causes inefficient string operations
in quite a few places.  E.g. to source the "syntax/syncolor.vim" script
you would first need to use sprintf into a buffer.

> > 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.

The warning is there:

### Location of Vim files (should not need to be changed, and
### some things might not work when they are changed!)


>     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 ;)

Mostly this can be done.   Cleans it up quite a bit.  Only reason I can
think of to keep the variables is to avoid confusion about using the
name for something else than the subdirectory name.

-- 
hundred-and-one symptoms of being an internet addict:
70. ISDN lines are added to your house on a hourly basis

 /// Bram Moolenaar -- [EMAIL PROTECTED] -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\        download, build and distribute -- http://www.A-A-P.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Reply via email to