[texdoc] Some small bugs and more
Karl Berry
karl at freefriends.org
Thu Nov 16 00:05:10 CET 2017
I somehow disagree. texdoc is *now* a tool for searching packages, but
that doesn't mean we cannot extend it.
Ok, I agree. Indeed, I was thinking about sending a second message
suggesting that "texdoc --type=command enumerate" could look up the
command/environment/whatever enumerate, instead of the package. And it
would do so by invoking a separate program.
What I was really thinking about was the existing source code to
texdoc. Trying to somehow mangle that into also being a full-text
search engine over a multi-gigabyte tree, or a PDF reader, or
.. no. The implementation has to be separate, or the program will
quickly become unmaintainable.
* provide some way to have plugins written in lua
Sure, sounds good.
* if the initial (and fuzzy) search fails, texdoc calls the plugins for
searches
* one plugin could be "latex2e" which reads the keyword/concept index
from the .info (or other way) and searches there.
Sure. Although if the fuzzy search is fuzzy enough, it will never fail.
Even now, "texdoc tabular" finds some (26) documents. They may not be
want this hypothetical newbie wants, but how is texdoc supposed to know
that? I highly doubt the scoring mechanism is robust enough to be a
basis for decision (but maybe). I think it has to be explicitly told.
* info_plugin that reads the indices from an .info/.texi document
Aside: latex2e exists in HTML, XML, and plain text also. So it's not
necessary to bother doing anything with the Info format per se.
I don't think it is necessarily a good idea to try to parse each and
every pdf we ship in texlive, but trying to get *some* documents
accessible would not be a bad move.
I don't know how a line could be drawn ... -k
More information about the texdoc
mailing list