Hi Bram :)
* Bram Moolenaar <[EMAIL PROTECTED]> dixit:
> DervishD wrote:
>
> > > Generally I find it quite strange to order application-specific files
> > > by their type instead of by the application.
> >
> > But that's a very sensible thing to do. This way you can partition
> > the hiearchy much more efficiently. For example, I have my /usr "zone"
> > backup recorded on a DVD, and the rest of my system is on a CD and a USB
> > pendrive. This way, if my hard disk decides to break, I can have my
> > system up and running again in less than 10 minutes, booting from the
> > CD, putting the read-write portion of my system in a ramdisk (under
> > Linux, I mean) and mounting my backup DVD as /usr. By dividing by type
> > and not by app, all read-only files are placed under the same mount
> > point. Take a look at the FHS standard for a much deeper rationale
> > (e.g., the division between /var and /usr, for example).
> >
> > I know, it is weird outside UNIX, and when I started to use Linux,
> > almost a decade ago, I found it very strange and mind boggling, but in
> > the end, that kind of filesystem structure has been a bless ;))
>
> There is a big difference between placing files by their properties
> (e.g. being static or dynamic) or by their filetype.
Not really, frequently the "filetype" is a property (for example,
libraries, binaries, etc.).
> In my opinion all
> static files of a certain version of a certain program can be put
> together. Only a few things might need to be spread to other
> directories, using symlinks when possible (binary in /usr/local/bin,
> libs in /usr/local/lib, header files in /usr/local/include).
Well, I know about a packaging system that does exactly that (I
don't remember its name). The problem is that maintaining that lot of
symlinks is a mess, usually. It's easier (and IMHO more convenient) to
use the installation system of the package to put the files where they
belong (again, IMHO) in the first place.
> > Of course, those kind of files should go under /usr/lib/vim: they
> > are static data needed for the program to run. If you modify them
> > frequently (and you shouldn't, because you have all the "/after" dirs
> > for modifying the vim runtime behaviour), you can place them under
> > /etc/vim, for example. I have my own runtime under /etc/vim because I
> > consider them configuration files and not exactly a runtime. Having the
> > documentation under /etc/vim is weird in that case.
>
> /etc is really a bad place for these files. Only files that contain
> configuration options should go there. Some systems do have a
> /etc/vimrc, but having system-wide editor defaults is not good. All the
> default option values, as documented in the help file, might actually
> be overwritten with different defaults then.
I understand your point: the machine users end up with a vim whose
default behaviour is not that of the documentation.
> > The point is: I should be able to put the application files,
> > separated by type, where they fit under my hierarchy, always under
> > common sense (for example, doesn't put help files under /var/lib/).
> > Things like autoconf or mobs do these kind of duties (amongs others).
>
> Autoconf only knows about generic things like man pages. You can't use
> that for Vim help files or other application-specific things.
But currently, with Vim, you can't use it either to set the runtime
(you must give "VIMRUNTIMEDIR" and "VIMRTLOC" to "make"), which should
be considered to go in "datadir".
> > And, BTW, I have my own vim runtime under /etc/vim, with no subdirs,
> > it is very small (only handles the filetypes I use, and indentation,
> > syntax and the like are fully adapted to my likings) and I have it
> > mirrored on a SVN server so I can go back and forth between revisions of
> > the files ;) It's weird, but I can do it because vim is flexible enough
> > to allow it (except for helpgrep, but that can be fixed without touching
> > the source code at all).
>
> It sounds very much like you actually have your personal things in
> system-wide directories.
Oh, not at all, it's only that all the users in my machine want more
or less the same set of defaults, so for me it's easier to put them in
the system wide vimrc instead of maintaining changes in every home
directory.
> > > Anyway, using the directory from 'helpfile' for ":helpgrep" should indeed
> > > be done. Otherwise it's not consistent with ":help".
> >
> > I think the same.
> >
> > > > I'm not familiar enough with the source to be able to add support
> > > > for "helpfile" path to "ex_helpgrep" without resorting to a dirty
> > > > hack, but I can try... "ex_helpgrep" looks like it is tailored to
> > > > only process "runtimepath/doc" in the main loop, so any nonintrusive
> > > > modification is almost impossible.
> > >
> > > I think that changing the source code would be the right thing to do.
> >
> > If you want, I can try to make the modification, but since I'm not
> > familiar with the code, I cannot make promises about the code quality
> > O:)
>
> Give it a try. I probably won't have time for it soon.
OK, I'll start working on it as soon as I can afford 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!
