all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
Cc: emacs-devel@gnu.org
Subject: Re: auto-update of Info dir file?
Date: Tue, 16 May 2006 21:14:28 +0300	[thread overview]
Message-ID: <upsid3khn.fsf@gnu.org> (raw)
In-Reply-To: <DNEMKBNJBGPAOPIJOOICAECODGAA.drew.adams@oracle.com>

> From: "Drew Adams" <drew.adams@oracle.com>
> 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	other threads:[~2006-05-16 18:14 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-05-15 15:28 auto-update of Info dir file? Drew Adams
2006-05-15 15:39 ` Andreas Schwab
2006-05-15 15:53   ` Drew Adams
2006-05-15 16:54     ` Andreas Schwab
2006-05-15 20:31 ` Eli Zaretskii
2006-05-16  3:54   ` Stefan Monnier
2006-05-16  4:17     ` Miles Bader
2006-05-16  6:00       ` David Kastrup
2006-05-16 17:39       ` Eli Zaretskii
2006-05-17  2:24         ` Miles Bader
2006-05-16 17:36     ` Eli Zaretskii
2006-05-16 17:54       ` Drew Adams
2006-05-16 18:14         ` Eli Zaretskii [this message]
2006-05-16 19:33           ` Drew Adams
2006-05-17  3:24             ` Eli Zaretskii
2006-05-16 19:44           ` Richard Stallman
2006-05-16 18:44       ` Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=upsid3khn.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.