bug#13160: 24.3.50; [PATCH] man page completion support beyond man-db

[Wolfgang Jenkner]

On Sun, Dec 23 2012, Stefan Monnier wrote:

>>> Does it fix an actual bug? [ Sorry if it does fix a real bug and this
>>> was mentioned somewhere in this thread, but I haven't found the time to
>>> read all threads as thoroughly as I'd like.  ]
>> My proposed change log entry indicates that the cache handling is rather
>> bogus (complete for "foo" then for "bar" and then for "foo" again and
>> "man -k ^foo" will be run again and the result prepended to the cache).
>
> Oh, indeed.  Fixed with the trivial patch below, tho.

Well yes, you nuke the old content, whis is what the previous versions
of my patches proposed here do as well, but this can hardly be called
a useful cache then.

>> The main reason, however, is that it eliminates any dependency on the
>> particular flavour of `man -k' output, so everything can be done in
>> elisp by the new Man-parse-apropos (I indicated that in the change log
>> entry, too).
>
> That indeed the part of the change log I did not understand.  How does
> the "man -k" argument relate to the "output flavor"?

Well, I wrote in the proposed change log:

        Conveniently, the change entails that we don't have to guess the
        output format of `man -k' in order to pass it a useful regexp.

The problem is that the page names are not necessarily anchored at the
beginning of a summary line (there are examples in the proposed
man-tests.el), so we can't always use "man -k ^foo" to find all summary
lines for man page names starting with "foo".  A previous version of the
patch posted here introduced a new variable holding a suitable regexp
`anchor', which, however, would depend on the output format of `man -k',
its flavour :-)

I think that parsing the full listing obtained with `man -k ^' is the
best solution, it's just that storing the result in a plain list is not
quite optimal, hence my babbling about tries.

I can wait with my changes until we've found a better data structure.

Wolfgang