bug#16407: Info-directory-list should always put this Emacs's info direc first

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Package: emacs
Version: 24.3
Severity: minor

The initialization of Info-directory-list is rather complicated.
Part of it uses this logic:

   Therefore, the directory of Info files that come with Emacs normally
   should come last (so that local files override standard ones), unless
   Emacs is installed into a non-standard directory. In the latter case,
   the directory of Info files that come with Emacs should be first in
   this list.

I don't think this logic makes sense any more. I think the directory of
Info files that come with Emacs should *always* be placed at the front of
the result (even before INFOPATH entries).

I assume the current logic dates from a time when it was thought likely
that a site might want to customize the Emacs info pages. I don't think
this happens any more. What I think does happen is people having
multiple versions of Emacs installed. In this case, I think Emacs
version N should always display the info pages associated with version N.
So Emacs should always put its own info directory first.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Date: Fri, 10 Jan 2014 00:46:39 -0500
> 
>    Therefore, the directory of Info files that come with Emacs normally
>    should come last (so that local files override standard ones), unless
>    Emacs is installed into a non-standard directory. In the latter case,
>    the directory of Info files that come with Emacs should be first in
>    this list.
> 
> I don't think this logic makes sense any more. I think the directory of
> Info files that come with Emacs should *always* be placed at the front of
> the result (even before INFOPATH entries).

That leaves system administrators no means of forcing a specific
version of Info manual to be found by default.  With INFOPATH taking
precedence, they can.

Also, Emacs comes with a few manuals that can have other versions from
elsewhere (like info.info or gnus.info).

> I assume the current logic dates from a time when it was thought likely
> that a site might want to customize the Emacs info pages. I don't think
> this happens any more. What I think does happen is people having
> multiple versions of Emacs installed.

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.  The only way to
have the correct results is either by "C-u C-h i" and point Emacs to
the specific file name, or run all but one version uninstalled.

> In this case, I think Emacs version N should always display the info
> pages associated with version N.  So Emacs should always put its own
> info directory first.

What if the user installs newer versions of, say, Gnus or Org from
their respective repositories?

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

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

> Also, Emacs comes with a few manuals that can have other versions from
> elsewhere (like info.info or gnus.info).

(IIRC, Karl has stated that he considers Emacs the canonical home for
info.info.)

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.

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

> What if the user installs newer versions of, say, Gnus or Org from
> their respective repositories?

See my comment above.
(Frankly, I suspect what happens at present in most such cases is that
people install the lisp files in their load-path, but do not do anything
with INFOPATH, so end up seeing the wrong Info pages anyway.)

And note that the Mac platform has already behaved as I request for some
years. I don't recall seeing any complaints.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Glenn Morris wrote:

>> Also, Emacs comes with a few manuals that can have other versions from
>> elsewhere (like info.info or gnus.info).
>
> (IIRC, Karl has stated that he considers Emacs the canonical home for
> info.info.)

Also, when I am using Emacs, I am using the info reader that comes with
that Emacs. So I cannot think of a reason why (info "info") should show
me anything but the info.info that came with that Emacs.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

PS I would accept a solution that only prepends Emacs's info directory
to the front of INFOPATH if it had a trailing ":", since that implies a
willingness to at least consider directories other than the ones in
INFOPATH.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 02:50:49 -0500
> 
> 
> PS I would accept a solution that only prepends Emacs's info directory
> to the front of INFOPATH if it had a trailing ":", since that implies a
> willingness to at least consider directories other than the ones in
> INFOPATH.

I think we should indeed do this.  Doing it in the general case runs a
much higher risk of ruining someone's use case.

Not sure whether even this smaller change could be done during a
feature freeze, though.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Eli Zaretskii wrote:

>> PS I would accept a solution that only prepends Emacs's info
>> directory to the front of INFOPATH if it had a trailing ":", since
>> that implies a willingness to at least consider directories other
>> than the ones in INFOPATH.
>
> I think we should indeed do this.

OK.

> Not sure whether even this smaller change could be done during a
> feature freeze, though.

No, it's obviously controversial and can wait.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 02:44:03 -0500
> 
> Also, when I am using Emacs, I am using the info reader that comes with
> that Emacs. So I cannot think of a reason why (info "info") should show
> me anything but the info.info that came with that Emacs.

You cannot control that anyway, because "make install" in Texinfo will
overwrite the version installed by Emacs, as they are (normally) in
the same /usr/share/info directory.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Eli Zaretskii wrote:

>> Also, when I am using Emacs, I am using the info reader that comes with
>> that Emacs. So I cannot think of a reason why (info "info") should show
>> me anything but the info.info that came with that Emacs.
>
> You cannot control that anyway, because "make install" in Texinfo will
> overwrite the version installed by Emacs, as they are (normally) in
> the same /usr/share/info directory.

I didn't explain well.
I was thinking of having several Emacs versions installed in different
directories. Obviously if you install them into the same prefix, the
info pages overwrite each other, and nothing can be done about that.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 15:05:57 -0500
> 
> I was thinking of having several Emacs versions installed in different
> directories.

You mean, configured with a different --prefix?  Do people actually do
this when installing programs, except when they are installed for a
single user under her home directory?  Do they do this frequently
enough for us to care?

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Glenn Morris wrote:

>> What if the user installs newer versions of, say, Gnus or Org from
>> their respective repositories?
>
> See my comment above.
> (Frankly, I suspect what happens at present in most such cases is that
> people install the lisp files in their load-path, but do not do anything
> with INFOPATH, so end up seeing the wrong Info pages anyway.)

PPS Actually, if they install via the Emacs package manager, there will
be no problem. That already does what I suggest: forces an entry on to
the very front of Info-directory-list. That would still come before the
element I am suggesting.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 03:05:13 -0500
> 
> PPS Actually, if they install via the Emacs package manager, there will
> be no problem.

Neither Gnus nor Org are in ELPA.  Does package.el support the
respective URLs for these (and other) packages that are not in ELPA?

Anyway, if we want to know the current state of affairs, we should
poll user of these packages, at least on this list.  I personally
don't install any of them.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Stefan Monnier]

> Neither Gnus nor Org are in ELPA.

Org is.


        Stefan

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Glenn Morris <rgm@gnu.org>,  16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 10:03:52 -0500
> 
> > Neither Gnus nor Org are in ELPA.
> 
> Org is.

Not in my clone:

  $ find . -name org.el
  (nothing)
  $ git log --pretty='format:%H' -1
  3ce7e03656204ec93d6de42cdbb14beaaa23aa4d

What am I missing?

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Rüdiger Sonderfeld]

On Friday 10 January 2014 17:16:44 Eli Zaretskii wrote:
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: Glenn Morris <rgm@gnu.org>,  16407@debbugs.gnu.org
> > Date: Fri, 10 Jan 2014 10:03:52 -0500
> > 
> > > Neither Gnus nor Org are in ELPA.
> > 
> > Org is.
> 
> Not in my clone:
> [...]
> What am I missing?

Org is fetched externally by `admin/org-synch.sh'.

Regards,
Rüdiger

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

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

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Eli Zaretskii wrote:

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

I don't really get your point. I contend that "Emacs N should show the
manuals for version N", without the user needing to do anything special.
(I'm assuming throughout that each Emacs version is installed in a
separate location, otherwise the info pages stomp all over each other
anyway, as you said.)

For example:

As a user, I have a local software directory /home/me/software, where I
install things. So I have INFOPATH=/home/me/software/info: in my
environment. There is Emacs version N in there. I have other Emacs
versions installed in other places, which I want to use at times. All of
them end up finding the info pages from Emacs version N.

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

Sorry, I think it's overly complicated for this day-and-age, and could
stand to be simplified.

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

It's me, I'm the complainer! :)

Anyway, my one sentence summary is that it just seems crazy to me that
Emacs does not reliably find its own info pages.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Eli Zaretskii]

> From: Glenn Morris <rgm@gnu.org>
> Cc: 16407@debbugs.gnu.org
> Date: Fri, 10 Jan 2014 15:11:45 -0500
> 
> Eli Zaretskii wrote:
> 
> > 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.
> 
> I don't really get your point. I contend that "Emacs N should show the
> manuals for version N", without the user needing to do anything special.

As I said, this is generally impossible.

> (I'm assuming throughout that each Emacs version is installed in a
> separate location, otherwise the info pages stomp all over each other
> anyway, as you said.)

But what happens in reality is either the stomping or the manual is
renamed into emacs-xx, to allow several versions of manuals coexist.

> Sorry, I think it's overly complicated for this day-and-age, and could
> stand to be simplified.

I suggest to look at a typical Debian system with several Emacs
versions installed, and see what kind of arrangement they use.  At the
time, this was one of the reasons for the complexity.  Maybe it no
longer exists, I don't know.

In any case, the problem with being able to control where Emacs looks
for the misc manuals still exists, for those Emacs packages that are
developed and distributed separately.

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Eli Zaretskii wrote:

> I suggest to look at a typical Debian system with several Emacs
> versions installed, and see what kind of arrangement they use.  At the
> time, this was one of the reasons for the complexity.  Maybe it no
> longer exists, I don't know.

They install the info pages into /usr/share/info/emacs-N (sensible).
And then they patch info.el so that it finds those first:

http://patch-tracker.debian.org/patch/series/view/emacs24/24.3+1-2/0001-Prefer-usr-share-info-emacs-24-over-usr-share-info.patch

So whatever info.el thought it was doing to suit Debian, it wasn't
enough anyway.

They should not have to have such a patch, it should work out of the box.

> In any case, the problem with being able to control where Emacs looks
> for the misc manuals still exists, for those Emacs packages that are
> developed and distributed separately.

I disagree that this is an issue.

1) No problem at all with package.el, before or after any change to info.el.

2) I have no data, but doubt this was a problem people were solving via
INFOPATH anyway.

3) To use a newer version of a built-in package, you have to customize
load-path. I maintain that it's fine to expect people to have to
customize Info-directory-list similarly. (Perhaps this part of info.el
should be preloaded to make this easier.)

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Glenn Morris]

Glenn Morris wrote:

> 2) I have no data, but doubt this was a problem people were solving via
> INFOPATH anyway.

I think I'm wrong there. It's problematic...

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Stefan Monnier]

> Anyway, my one sentence summary is that it just seems crazy to me that
> Emacs does not reliably find its own info pages.

FWIW, I completely agree.  Tho to me the main problem is that Emacs
should not behave differently when "installed into a non-standard
directory" and when not.


        Stefan

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Achim Gratz]

Glenn Morris writes:
> (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.)

I think you assume too much sophisication of a sysadmin who will
typically know little about the intricacies of Emacs.  In any case, the
examples of site-lisp customization that I've been exposed to lately
have forced me to add "--no-site-lisp" to my all Emacs invocations.

> 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 problem is that it's not immediately obvious when the two are not
kept in sync; something that presumably package manager should solve,
but doesn't.  It would help if the built-in packages could be completely
deactivated upon installation of a different version of that same
package via package manager (that is, the custom-load and autoload stuff
for such a package delivered with Emacs should not be evaluated in that
case).

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

… while someone else might reaonably expect that he'll get the version
of the manual that he's installed first or last.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptation for Waldorf rackAttack V1.04R1:
http://Synth.Stromeko.net/Downloads.html#WaldorfSDada

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Lars Ingebrigtsen]

Glenn Morris <rgm@gnu.org> writes:

> The initialization of Info-directory-list is rather complicated.
> Part of it uses this logic:
>
>    Therefore, the directory of Info files that come with Emacs normally
>    should come last (so that local files override standard ones), unless
>    Emacs is installed into a non-standard directory. In the latter case,
>    the directory of Info files that come with Emacs should be first in
>    this list.
>
> I don't think this logic makes sense any more. I think the directory of
> Info files that come with Emacs should *always* be placed at the front of
> the result

I agree completely.

The info setup is pretty convoluted, so I'm not quite sure what the
current state is.  This is the default value in "emacs -Q" in Emacs 29:

Info-directory-list
("/home/larsi/src/emacs/trunk/info/" "/usr/share/info/")

But it's with an uninstalled Emacs.  Reading Info-default-dirs, it looks
like it's trying to do the right thing?  So has this been solved already
at some point?

> (even before INFOPATH entries).

But I'm not sure about that.  I don't think distributions set that by
default, but users do to alter stuff, so we should respect it.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#16407: Info-directory-list should always put this Emacs's info direc first

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> The info setup is pretty convoluted, so I'm not quite sure what the
> current state is.  This is the default value in "emacs -Q" in Emacs 29:
>
> Info-directory-list
> ("/home/larsi/src/emacs/trunk/info/" "/usr/share/info/")
>
> But it's with an uninstalled Emacs.  Reading Info-default-dirs, it looks
> like it's trying to do the right thing?  So has this been solved already
> at some point?
>
>> (even before INFOPATH entries).
>
> But I'm not sure about that.  I don't think distributions set that by
> default, but users do to alter stuff, so we should respect it.

It seems to me like Emacs 29 is putting Emacs' info directory first, so
I'm closing this bug report.  (I may be mistaken, and there's some cases
where that doesn't happen, but I haven't been able to reproduce it -- if
somebody has a case for reproduction, please go ahead and open a new bug
report.)

(And I still agree with myself that INFOPATH should take precedence.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no