Re: Weird problem with helpgrep
Hi François :) * François Pinard [EMAIL PROTECTED] dixit: [DervishD] [Bram Moolenaar] 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). [...] I used two installation systems which were extremely fond on symbolic links: LUDE (from Université de Montréal) and Stow (from GNU). Both have been used in various places. Stow!, that's the name I didn't remember :) Thanks for pointing! 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!
Re: Weird problem with helpgrep
[DervishD] [Bram Moolenaar] 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. Hi, people. Just perusing email in ultra-fast mode :-). I did not read the previous exchanges, so I apologize if I'm out of context. I used two installation systems which were extremely fond on symbolic links: LUDE (from Université de Montréal) and Stow (from GNU). Both have been used in various places. LUDE was a bit gigantic for my own needs, I've never really been comfortable with it. Stow was OK and clean (not so messy). Even if I was careful to be stow-compatible for a few packages I maintained in another life, I nowadays prefer installations to be plain straight. -- François Pinard http://pinard.progiciels-bpi.ca
Re: Weird problem with helpgrep
Hi Bram :) * Bram Moolenaar [EMAIL PROTECTED] dixit: DervishD wrote: Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? Vim documentation must be in the runtime directory. It doesn't make any sense to put it below /usr/doc. These are help files, not generic documentation files. I hadn't seen this from that point of view. For me they were documentation (as things you put under /usr/doc) rather than help files (as things you probably should place under /usr/lib). 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 ;)) 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. 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. 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). 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). 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:) Thanks for your answer :) 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!
Re: Weird problem with helpgrep
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
Re: Weird problem with helpgrep
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? [...] Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use :helpgrep O:) Here, :help E480 shows help about :argdelete, and the help tags :argd :argdelete and E480 are on a single line. It should show help about the No match, am I wrong? Maybe you are using wrong syntax? To use your own example, the syntax to search for most as a separate word is :helpgrep \most\ I've tried that, too. The problem is that :helpgrep doesn't find any help file because it is not searching for where the help is really installed. 1) Use :vimgrep instead of :helpgrep. The syntax is different but you ought to get access to the same results, albeit not in a help window but in the current window (use :new before :vimgrep to do it in a new window). To use the same example again (and an imaginary directory location): :vimgrep /\most\/g ~/mydocs/vim/doc/*.txt As a variation of this, you could use the following: command -nargs=1 -bar HelpGrep vimgrep /args/g ~/mydocs/vim/docs/*.txt cabbrev HG HelpGrep You could then use :HelpGrep (or :HG) instead of :helpgrep. If you don't need the abbreviation, then of course you can skip the cabbrev definition. I think that's the better idea, thanks a lot :) I never thought about using :vimgrep :)) 2) Don't set 'helpfile' but create softlinks from the standard location to the actual location. (This requires the ability to create softlinks, which is easily available in Unix/Linux and Cygwin, but is absent, undocumented or esoteric on most native-Windows systems, unless shortcuts provide the same functionality.) 3) Bite the bullet and move the docs to their standard location. This ought not to require a recompilation. I don't like either solution: while I respect Bram's decision about where to put Vim files, Vim is breaking the standard here under Linux, and it can be easily fixed by, instead of hardcoding /doc/ in the source code and look in runtimepath, it used something like HELPSUBDOC and HELPSUBDIR (which, btw, are already in the file src/Makefile). Thus, by changing a couple of building options, things will work seamlessly. By now I'll use your suggestion about a new command, but if Bram wants, I can prepare a patch to replace the hardcoded directories by build-time constants or even run-time variables. That will take some time, but it can be done one-dir-at-a-time. I'll post this on the list just in case Bram doesn't read this message. Thanks a lot, Tony : 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!
Re: Weird problem with helpgrep
DervishD wrote: Hi Bill :) * Bill McCarthy [EMAIL PROTECTED] dixit: On Sun 28-Jan-07 4:33pm -0600, DervishD wrote: Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! If that's the case, you could add the path to vimruntime. That won't work, because docs are not in /usr/doc/vim/doc, but in /usr/doc/vim. Otherwise it would work. On my system, documentation is under /usr/share/doc/packagename (the share part is variable, since I maintain two different systems, one with shareable data and other withouth share). Thanks a lot for the suggestion :) Raúl Núñez de Arenas Coronado Well, you could, rather than setting 'helpfile', use the following then (in your friendly *sh shell): cd /usr/share/vim/vim70 ln -sv ../../doc/vim doc Or else (the next time you install everything) use make install with default paths (i.e. /usr/local/vim/vim70 and /usr/local/vim/vim70/doc), and use, if you want it, cd /usr/local/share/vim ln -sv vim70 latest cd /usr/doc ln -sv ../local/share/vim/latest/doc vim You could even leave everything as-is, and use cd /usr/doc/vim ln -sv . doc to make /usr/doc/vim/doc synonymous with /usr/doc/vim. Soft links are powerful! Best regards, Tony.
Re: Weird problem with helpgrep
Hi Tony :) * A.J.Mechelynck [EMAIL PROTECTED] dixit: DervishD wrote: That won't work, because docs are not in /usr/doc/vim/doc, but in /usr/doc/vim. Otherwise it would work. On my system, documentation is under /usr/share/doc/packagename (the share part is variable, since I maintain two different systems, one with shareable data and other withouth share). Well, you could, rather than setting 'helpfile', use the following then (in your friendly *sh shell): cd /usr/share/vim/vim70 ln -sv ../../doc/vim doc [...] Well, usually I don't like to have the system full of symlinks to fix this kind of problems. Using symlinks, you can have your apps installed using a Windows-like scheme (you know, that crap called Program Files) while having an UNIX compliant hierarchy, but that's not a good idea. But... You could even leave everything as-is, and use cd /usr/doc/vim ln -sv . doc ...this is how I have set it right now to avoid problems and to avoid modifying the source. Even though, I still think that this is not the way: hardcoded patchs are, generally, not a good idea. Soft links are powerful! Yes!, but they can become a mess ;)) But you're right, they're very handy, specially for fixing this kind of situations :))) 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!
Re: Weird problem with helpgrep
DervishD wrote: I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? Vim documentation must be in the runtime directory. It doesn't make any sense to put it below /usr/doc. These are help files, not generic documentation files. Generally I find it quite strange to order application-specific files by their type instead of by the application. 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). Anyway, using the directory from 'helpfile' for :helpgrep should indeed be done. Otherwise it's not consistent with :help. 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. -- hundred-and-one symptoms of being an internet addict: 60. As your car crashes through the guardrail on a mountain road, your first instinct is to search for the back button. /// 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///
Weird problem with helpgrep
Hi all :) I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? 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. Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use :helpgrep O:) Thanks a lot in advance :) 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!
Re: Weird problem with helpgrep
DervishD wrote: Hi all :) I've discovered that :helpgrep pattern doesn't work for me, always returning E480 (BTW, :help E480 shows help about argdelete, as if E numbers in source code and docs weren't synchronized). But that's not the weird part. If I search for a very common word (let's say most, for example), helpgrep returns the E480 error and it does *lightning fast!*. That's the weird problem it is not doing the search at all, and the E480 error is probably masking the real problem, which I couldn't isolate. Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! Given that /usr/doc or /usr/share/doc are pretty standard when it comes to install documentation, shouldn't ex_helpgrep use the directory from helpfile too, just like :help does? 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. Any suggestion instead of modifying the sources *and* moving the documentation? I would like to use :helpgrep O:) Thanks a lot in advance :) Raúl Núñez de Arenas Coronado Here, :help E480 shows help about :argdelete, and the help tags :argd :argdelete and E480 are on a single line. Maybe you are using wrong syntax? To use your own example, the syntax to search for most as a separate word is :helpgrep \most\ Notice that there are no / or around the pattern, and that where to search is implicit. On my system, the above command finds 255 hits, the first of which is in matchit.txt (not in $VIMRUNTIME/doc but, IIRC, as $VIM/vimfiles/doc/matchit.txt which is a softlink to ../../vim70/macros/matchit.txt ). Or if you are using correct syntax, maybe you have a mapping or abbreviation tripping you? (Try it with vim -N -u NONE after setting 'helpfile' and whatever other options you really can't do without.) Here are a few ways to access the documentation if it is in a nonstandard location: 1) Use :vimgrep instead of :helpgrep. The syntax is different but you ought to get access to the same results, albeit not in a help window but in the current window (use :new before :vimgrep to do it in a new window). To use the same example again (and an imaginary directory location): :vimgrep /\most\/g ~/mydocs/vim/doc/*.txt As a variation of this, you could use the following: command -nargs=1 -bar HelpGrep vimgrep /args/g ~/mydocs/vim/docs/*.txt cabbrev HG HelpGrep You could then use :HelpGrep (or :HG) instead of :helpgrep. If you don't need the abbreviation, then of course you can skip the cabbrev definition. 2) Don't set 'helpfile' but create softlinks from the standard location to the actual location. (This requires the ability to create softlinks, which is easily available in Unix/Linux and Cygwin, but is absent, undocumented or esoteric on most native-Windows systems, unless shortcuts provide the same functionality.) 3) Bite the bullet and move the docs to their standard location. This ought not to require a recompilation. Best regards, Tony.
Re: Weird problem with helpgrep
On Sun 28-Jan-07 4:33pm -0600, DervishD wrote: Finally, examining the source code, I found the problem. I have my vim documentation installed in /usr/doc, which is where all documentation is installed on my system. I've set helpfile so :help finds the docs. BUT :helpgrep doesn't use helpfile, but only runtimepath/doc. This is a problem for me, because no matter which value I assign to runtimepath, the documentation is not going to be found in any /doc subdir! If that's the case, you could add the path to vimruntime. For example, if your vim70 docs are in /usr/doc/vim70/doc: set rtp+=/usr/doc/vim70 An alternate idea, which will only search the distributed help files, is to add a command: command! -nargs=1 HG let g:myrtp = rtp \ | let rtp = '/usr/doc/vim70' \ | exe 'helpg args' \ | let rtp = g:myrtp \ | unlet g:myrtp Of course, to search all docs, including add-on help files, replace: \ | let rtp = '/usr/doc/vim70' with \ | set rtp+=/usr/doc/vim70 in another command, perhaps called HGA. -- Best regards, Bill
