RE: auto-update of Info dir file?

["Drew Adams" <drew.adams@oracle.com>]

    > The end user might not know that s?he wants a particular manual.

    ??? Really?

Really.

    Tell me, when you want to read some manual, how do you
    get to it if not by "C-h i d m MUMBLE <RET>" (or something
    equivalent)?  In other words, you _always_ name the manual that you
    want to read.

I don't want to belabor this, but my answer is no, I do not use `C-h i d m'
or `C-h i m' very often, and I suspect that some other users might not
either. I use `C-h i' and then click the manual's link in the menu.

Of course that's equivalent, but some users will use Info in an exploratory
fashion, to discover more of what is available. I have probably never looked
at at least 2/3 of the manuals that are in my `dir', but I might someday. If
I do, the first thing I will do is browse the list to see what I might be
interested in. That requires that the list be complete (populated).
Preferably, the list would be complete not only with file names but also
with brief descriptions (perhaps constructed automatically).

Yes, the `m' command, if fixed as you proposed (a la standalone `info'),
would let people explore via completion, so that's a good start. But why not
populate the _visible_ menu too, while we're at it? Why populate only the
invisible "menu" provided by `m' completion?

When you go to the library or bookstore, do you always go looking for a
particular book? Don't you sometimes browse the shelves to see what might be
interesting?

    > If the manual doesn't appear in the Info list (catch-22),
    > then the user might not even be aware that the manual exists.

    How long is your top-level menu?

On Emacs 20 on Windows: 28 manuals.
On Emacs 22 on Windows: 41 manuals.

    Mine is _very_ long, and the same
    will happen to anyone who has glibc docs installed, because they add
    an entry for each and every function in the library.  But even if
    there's no glibc entries in DIR, a garden variety top-level menu is
    quote long: for example, the one on gnu.org machines has 623 lines.

Well, yours is certainly longer than mine, Eli! ;-)

    So, to avoid wasting precious time, I _never_ scan the menu to find
    whether a topic I'm looking for is there, I type "m SOMETHING <RET>"
    and watch the result: if there's no such topic, Info will bitch at me.

Different users have different use patterns. Different users have different
menus. Different users have different sizes. I've been known to browse a
bookstore or library no matter how big it is (Library of Congress?). Call me
inefficient.

You really raise a different issue, I think, which is how to help users
manage a long `dir' menu? It might be useful to brainstorm ideas in that
area. Perhaps structuring the menu more? Perhaps providing a special search
functionality for it? I agree that the completion available via the `m'
command is useful in this regard (<ad>especially with Icicles
completion!</ad>), but perhaps there is room for additional help.

Library and bookstore card catalogs and computerized searches for books make
it possible to manage even _humongous_ inventories of books as an end user.
And they are not limited to, say, the equivalent of `C-h i d m
<ISBN-number>'.

Nevertheless, there is still a need (rather, a preference) on the part of
some users in some libraries on some rainy days to browse some of the stacks
and peruse some of the books. Some people never learn (`C-h i d m').

    > The idea was to have invocation of Emacs command `info'
    > populate Info with all available manuals, without the
    > end user needing to know anything about what they are.

    And I thought the idea was to allow the user to reach a manual even
    though it was not installed by `install-info'.

That's a consequence of the idea I proposed, which was to populate the menu
automatically. And yes, that is desirable. But it's not the full goal.

    Populating the top-level menu with all manuals is a means
    to an end; I suggested a different means to the very same end,
    I think.

The end is not the same if the end is reduced to a limited way (invisible
menu) to "reach a manual". I would like to see the visible menu populated
too, so users, especially novice users, can browse what they see there -
that's part of the end pursued by my proposal, it's not just a means to it.

    > Also, how will Emacs tell what "the user wants" in this
    > context? Even if the end user does know that s?he wants
    > a particular manual (and that it should
    > be available), how is that communicated to Emacs in your scenario?

    It's the string the user types at `m's prompt in the top-level menu.

Too limiting; see above.

    > I think this should be push rather than pull. That is, populating
    > Info should not be demand-driven by the user; it should be done
    > automatically, based on all available Info files. It can be
    > demand-driven in terms of _when_ it happens (dynamically, when
    > the user invokes Emacs command `info' for the first time in a
    > session), but not in terms of _which_ manuals end up
    > populating the `dir' file.

    I didn't say anything about populating the menu.  My suggestion
    involves no modifications to the menu, Info will just find the manual
    even if it isn't in the menu.

_I_ did say something about populating the menu, right from the start. My
proposal is different from yours, not only in the means, but also in the end
pursued. Making sure that completion for `m' has the complete list of books
is necessary, but it is not sufficient. The visible menu should also be
complete.

    To see how the stand-alone Info reader handles this, type at the
    shell's prompt "info info-stnd".  There should be no menu entry that
    begins with the string "info-stnd" in your DIR file, but the
    stand-alone reader will find the right manual anyway.

Yes, I have no problem with that, as far as it goes. I would also like to
see the visible menu show what's available, so users don't need a crystal
ball before they can know to type "info info-stnd". Even if seen in a
completion list, "info-stnd" is hardly parlant. The same thing goes for the
visible menu: It would be good to find some way to add a (constructed)
description for the books added automatically to the (visible) menu.

Ideally (another, future discussion, perhaps), users should be able to type
keywords or a regexp and see a summary of the hits among all manuals - to
see which manuals might be available and most appropriate for info on a
particular subject.

To me, this is about helping users to know which manuals are available. It
is not just about "reaching a manual" that you know you want to read.