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. 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). Config file goes in /usr/local/etc, dynamic things below /var somewhere. I don't see a reason to move documentation files, unless they are in a standard format and will be found by generic tools. There is a standard place for man pages, of course (well, ignoring language and encoding, there doesn't seem to be a widely used standard for that). > > You scatter files all over the system and are left with files that you > > don't know where to put (there is no /usr/syntax, /usr/indent or > > /usr/vimplugins). > > 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. > But that's not the point. The point is that I may not want to use > the default runtime. Then, where should I put the documentation for Vim? > OK, they may count as help files, and so they should go under > /usr/lib/vim/doc, no problem with that. But imagine I have a system > which indexes ALL documentation in my system. Then I'll prefer to have > all the documentation under /usr/doc. You could put a copy of the Vim help there, if your indexing system can handle it (never seen that). I would not _move_ it there. Using symlinks would come in handy. Nevertheless, if somehow the format of the Vim runtime files change (e.g., help files are compresed), your system will fall down. > 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. > 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. > > 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. -- hundred-and-one symptoms of being an internet addict: 71. You wonder how people walk /// 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 ///
