From: Eli Zaretskii <eliz@gnu.org>
To: Glenn Morris <rgm@gnu.org>
Cc: 16407@debbugs.gnu.org
Subject: bug#16407: Info-directory-list should always put this Emacs's info direc first
Date: Fri, 10 Jan 2014 10:19:18 +0200 [thread overview]
Message-ID: <8338kwckqh.fsf@gnu.org> (raw)
In-Reply-To: <4s4n5cl20f.fsf@fencepost.gnu.org>
> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 02:38:56 -0500
>
> Eli Zaretskii wrote:
>
> > That leaves system administrators no means of forcing a specific
> > version of Info manual to be found by default.
>
> That is true, it does not, but only for manuals that come with Emacs.
They are a plenty.
> I cannot think of a case where a *sysadmin* would want to force
> Emacs to prefer some other version of a manual to the one that comes
> with Emacs. Can you give an example?
On a multi-user system, INFOPATH can be customized differently for
each user, but /usr/share/info is a single directory. Suppose some
users want to stay with an older Emacs, while others want the bleeding
edge.
> (And they could always do it with some site-specific elisp if they
> really wanted to. But I expect it to be very much a fringe case.)
Experience has taught us that there are too many "fringe cases" when
Info docs are concerned. The code to which you pointed was a result
of prolonged discussions in the past, and many micro-corrections due
to these fringe cases. Eventually, some of the use cases stay
unsupported, and AFAIR cannot be supported without hurting no less
important cases, because Info simply is not designed for there being
several manuals by the same name on INFOPATH.
> By default, Emacs uses the Gnus that comes with Emacs.
> To get it to use a different Gnus, you have to customize load-path.
> I do not think it unreasonable that you should have to similarly
> customize Info-directory-list to get the right manual.
The question is not what's reasonable. The question is do people (or
"make install" of those packages) actually do that.
> > Is this the only situation where the current arrangement doesn't DTRT,
> > or are there more? If this is the only one, then you cannot solve it
> > successfully: the Info system simply doesn't support well the use case
> > where several different manuals have identical names.
>
> I don't understand why it cannot be solved successfully by doing what I
> said. I don't care about seeing multiple versions of the manuals with
> the same name, I want to see only one version, and I want that version
> to be the version that comes with Emacs.
Again, since Emacs, like every other package, installs its Info files
in a single global directory, you don't actually know what is "the
version that comes with Emacs", except when Emacs runs uninstalled (in
which case it already does what you want). All you know is that
there's some FOO.info file in /usr/share/info. If it is overwritten,
you don't know that. So this problem is in general unsolvable.
> And note that the Mac platform has already behaved as I request for some
> years. I don't recall seeing any complaints.
This goes both ways: I don't recall complaints about the current
arrangement, either.
next prev parent reply other threads:[~2014-01-10 8:19 UTC|newest]
Thread overview: 24+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-01-10 5:46 bug#16407: Info-directory-list should always put this Emacs's info direc first Glenn Morris
2014-01-10 7:16 ` Eli Zaretskii
2014-01-10 7:38 ` Glenn Morris
2014-01-10 7:44 ` Glenn Morris
2014-01-10 7:50 ` Glenn Morris
2014-01-10 8:07 ` Eli Zaretskii
2014-01-10 20:03 ` Glenn Morris
2014-01-10 8:09 ` Eli Zaretskii
2014-01-10 20:05 ` Glenn Morris
2014-01-10 20:20 ` Eli Zaretskii
2014-01-10 8:05 ` Glenn Morris
2014-01-10 8:21 ` Eli Zaretskii
2014-01-10 15:03 ` Stefan Monnier
2014-01-10 15:16 ` Eli Zaretskii
2014-01-10 16:36 ` Rüdiger Sonderfeld
2014-01-10 8:19 ` Eli Zaretskii [this message]
2014-01-10 20:11 ` Glenn Morris
2014-01-10 20:36 ` Eli Zaretskii
2014-01-10 21:03 ` Glenn Morris
2014-01-10 23:21 ` Glenn Morris
2014-01-10 20:54 ` Stefan Monnier
2014-01-10 19:47 ` Achim Gratz
2022-04-23 14:28 ` Lars Ingebrigtsen
2022-05-22 11:33 ` Lars Ingebrigtsen
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=8338kwckqh.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=16407@debbugs.gnu.org \
--cc=rgm@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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).