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

[Gavin Smith]

On 3 August 2015 at 22:55, Karl Berry <address@hidden> wrote:
>     Perhaps it's naive, but I feel like I might just want a dir like this so
>     that I can find what I want and don't have to change global state and/or
>     restart the viewer just to read different versions:
>
> I agree.  You can have that now.  It does not need new features, so far
> as I can see.  Just put the entries you want in the dir file.  When
> compiling emacs24.5, use configure --infodir=/usr/share/info/emacs24.5,
> etc.
>
> * Emacs (emacs.info)::
> * Emacs24.5 (emacs24.5/emacs.info)::
> * Emacs24.1 (emacs24.1/emacs.info)::

There's the problem of how to generate these dir entries, without
having the user type them into "dir" by hand. That's why I think it
would be useful for install-info to be able to do some transformation,
along with a transformation of the filename. (Karl, please explain why
you think this is a bad idea.) I know there is already the --entry
option, but that requires typing all the dir entries out, which is
about as inconvenient as editing "dir".

> And then your update-alternatives sets up the stuff like
> ln -s emacs24.5/emacs.info /usr/share/info/emacs.info
> so that cross-refs work.

If you don't care about being able to access renamed files via
cross-references, then the renaming of files to include versions is
good enough. If INFOPATH is the string "PATH", then the Info file
search path is deduced from the value of the PATH environmental
variable, so "info foo" should match the documentation for running
"foo". Then there would only be one "foo.info" manual reachable for
each element in PATH (those other than the first can be accessed with
"info --all foo"). This means that "info foo" can only give the manual
for a particular version of foo if there is an executable called "foo"
somewhere in the PATH (assuming a sensible setup). Otherwise you'd
have to do "info foo-12.34" instead. This relegates that manual to a
second-class status, but that isn't too bad, because the corresponding
executable is also second-class when it comes to the shell finding it.

The only real alternative is to give Texinfo some awareness of
different versions of manuals, which it doesn't have at the moment,
beyond searching for manuals in its search path, which is IMO good
enough. I share Karl's doubts about making Texinfo more complicated in
this way.