emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: auto-update of Info dir file?


From: Eli Zaretskii
Subject: Re: auto-update of Info dir file?
Date: Tue, 16 May 2006 21:14:28 +0300

> From: "Drew Adams" <address@hidden>
> Date: Tue, 16 May 2006 10:54:09 -0700
> 
>     I think we could solve the problem much easier: if the user wants a
>     manual called "mumble",
> 
> What do you mean here by "the user wants"? Are you speaking of the user who
> executes Emacs command `info' or the user (perhaps a sysadmin or programmer,
> not necessarily the end-user of Emacs) who adds the Info files to the
> directory?

The former.

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

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

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

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.

My suggestion is to try SOMETHING.info etc. if DIR has no menu item by
that name.

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

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

>     and there's no such entry in DIR, look for a
>     _file_ called `mumble' with several possible extensions.  This is what
>     the stand-alone Info does, so adding this to Emacs will increase
>     compatibility between the two readers.  Doing this bears no run-time
>     penalty, and almost the same benefits for the user.
> 
> 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.

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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]