Re: Weird problem with helpgrep

2007-02-01 Thread DervishD
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

2007-01-31 Thread François Pinard

[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

2007-01-31 Thread DervishD
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

Re: Weird problem with helpgrep

2007-01-30 Thread Bram Moolenaar

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 woul

Re: Weird problem with helpgrep

2007-01-30 Thread DervishD
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

2007-01-29 Thread Bram Moolenaar

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


Re: Weird problem with helpgrep

2007-01-29 Thread DervishD
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/ (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

2007-01-29 Thread A.J.Mechelynck

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/ (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

2007-01-29 Thread DervishD
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 \

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 /\/g ~/mydocs/vim/doc/*.txt
> 
> As a variation of this, you could use the following:
> 
> command -nargs=1 -bar HelpGrep vimgrep //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

2007-01-29 Thread DervishD
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/ (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

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

2007-01-28 Thread Bill McCarthy
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 '
\ | 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



Re: Weird problem with helpgrep

2007-01-28 Thread A.J.Mechelynck

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 \

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 /\/g ~/mydocs/vim/doc/*.txt

As a variation of this, you could use the following:

command -nargs=1 -bar HelpGrep vimgrep //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.