On 3 August 2015 at 22:55, Karl Berry <k...@freefriends.org> 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. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org