[texdoc] Some small bugs and more

Pathe Lists pathe.lists at gmx.com
Wed Nov 15 23:00:33 CET 2017


Hi all, and thank you for your replies and comments. As I was offline while travelling, I took me time to reply; sorry for that.

My only purpose is to make texdoc more efficient to newbies. As this tool is now well known, I hardly believe it would make much sense to create a completely new tool. It makes more sense having newbies getting used to it, rather than offering them a new tool-for-newbies.

Newbies only use a basic set of commands. As they are new to LaTeX, they refer to the manuals all the time, and try things like "texdoc tabular". And they get disappointed while getting "Tabulars with eledmac" instead of a tabular-howto. In that case, texdoc's answer should be better.

There are three scenarios:
"texdoc highspeedtrains" is a request making no sense, and we don't need to care about it.
"texdoc pssolid" is almost equivalent: "\pssolid" is a command offered by the pst-solides3d package, and it is obviously impossible for texdoc  to know about every LaTeX command.
"texdoc tabular" looks like a weird request; but from a newbie point of view, it is an obvious request. We might not like this scenario, but it exists; I think texdoc has to offer better replies to such queries. Because a disappointed newbie gives up easily.

This is the only thing I am talking about: I don't want to write a comprehensive LaTeX macros documentation or whatever. I just call for an enhancement of texdoc's behaviour, for a very limited set of commands.
 
Patrick


Sent: Wednesday, November 15, 2017 at 8:55 AM
From: "Norbert Preining" <norbert at preining.info>
To: pathe.lists at gmx.com, texdoc at tug.org
Subject: Re: [texdoc] Some small bugs and more
Hi Patrick, Karl, all,

> 2. As others have written, and as I wrote in my earlier reply,
> http://tug.org/pipermail/texdoc/2017q4/000412.html
> I don't think texdoc is the place to do it. texdoc is about finding

I somehow disagree. texdoc is *now* a tool for searching packages, but
that doesn't mean we cannot extend it.

I agree that implementing a general search engine for macros/concepts
etc is not realistic, but my ideas are:
* provide some way to have plugins written in lua
* 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.

There could be general plugins
* info_plugin that reads the indices from an .info/.texi document
* pdf_plugin that tries to extract info from pdfs
etc.

Then there could be a texdoc configuration
plugins =
info_plugin("latex2e.info")
info_plugin("tds.info")
pdf_plugin("graphics.pdf")
...

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.

Norbert

--
PREINING Norbert http://www.preining.info[http://www.preining.info]
Accelia Inc. + JAIST + TeX Live + Debian Developer
GPG: 0x860CDC13 fp: F7D8 A928 26E3 16A1 9FA0 ACF0 6CAC A448 860C DC13



More information about the texdoc mailing list