Re: Bug#793067: Bug#792328: info: can no longer find the Emacs manual

[Eli Zaretskii]

> Date: Tue, 4 Aug 2015 08:10:23 +0900
> From: Norbert Preining <address@hidden>
> Cc: address@hidden, address@hidden, address@hidden
> 
> lots of mails here, but I still don't see why you are opposing
> the idea to have different versions of the same program installed,
> and wanting to be able to *check* all of them.

AFAIU, only because it seems to be unworkable.

> On Mon, 03 Aug 2015, Karl Berry wrote:
> > If you're globally changing the meaning of the "emacs" binary, why
> > wouldn't you want "info emacs" to change with it?
> 
> That is fine, that *should* happen.
> If emacs points to emacs24, then the info emacs should you drop
> also into the emacs24 info.

Once again, how this magic would happen with cross-references between
manuals?  Large packages, such as Emacs and Texinfo, come with several
manuals which extensively reference each other.  Without solving this
problem, any suggestion will only be a trigger for endless bug
reports.

> But I might still want to be able to read several manuals without
> too many concoctions. Emacs is a bad example, python is a better.
> The division between python2 and python3 is now continuing since
> long, and many scripts are written for python2, which is the default
> on Debian. But I might want to adapt my script to python3 and want
> to be able to read python3 info.

There's no argument about the need.  The argument is about the
proposed solutions.

> ANyway, I wan to return to the proposal I wrote some time ago and
> that was discarded as not working (or unclear):
> 
> Change info reader node search method as follows:
> * if a node is going to be followed, first search *in*the*current*directory*
>   for the respective info file, and if that fails search INFOPATH.

We already do something like that, albeit not always: if you say

  info -f /foo/bar/baz.info

then the directory /foo/bar is added to INFOPATH.  It is currently
appended instead of being prepended, but that's easy to change.  It
should also be easy to add the directory of any file we load.

But I still don't see how this will solve the issue at hand.  With
several different versions of the same manual installed, how can you
ensure the other manuals it references are in the same directory?

> That way one can:
> * put files into subdirs
> * links within the same suite work (emacs shipping lots of related info docs)

Not necessarily: people tend to install Gnus, Org, and other large
bundled packages from their respective repositories, so even thus
problem is not entirely solved by your suggestion.

> * links to external progs will use the default version by searching
>   in INFOPATH

Which might not be what the user wants.  To repeat my example again,
imagine that I have several versions of GCC and several versions of
GDB, and want to use a specific combination of them.  How will you
ensure the links from the GDB manual load the GCC manual of the
version I want to use?

> I don't see disadvantages of this approach, but I am happy to listen to
> explanations.

The disadvantage is that it doesn't solve all the user cases.  Partial
solutions to this already exist; adding more will just muddy the
waters without putting the issue to rest once and for all.