C-h C-f can't find a file C-h i is displaying ! (nonurgent)

[Edward Welbourne]

This bug report will be sent to the Free Software Foundation,
not to your local site managers!
Please write in English, because the Emacs maintainers do not have
translators to read other languages for them.

Your bug report will be posted to the bug-gnu-emacs@gnu.org mailing list,
and to the gnu.emacs.bug news group.

In GNU Emacs 21.2.1 (i386-debian-linux-gnu, X toolkit, Xaw3d scroll bars)
 of 2002-03-22 on raven, modified by Debian
configured using `configure  i386-debian-linux-gnu --prefix=/usr 
--sharedstatedir=/var/lib --libexecdir=/usr/lib --localstatedir=/var/lib 
--infodir=/usr/share/info --mandir=/usr/share/man --with-pop=yes --with-x=yes 
--with-x-toolkit=athena --without-gif'
Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: C
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Please describe exactly what actions triggered the bug
and the precise symptoms of the bug:

OK, so I'm looking at the emacs info manual's "Command and Function
Index" when I remember I've had C-h C-f fail sometimes, so I give it a
blast.  I select a likely-looking entry in the index and check I can
get help on it with C-h f - no problem.  Then I C-h C-f it and get
told that emacs can't find an info file it's displaying !  (See recent
input and messages, below.)

I've got
  INFOPATH=/usr/share/info:/usr/info
in my environment and /usr/share/info/emacs-21/ contains emacs.gz and
emacs-*.gz for * = 1 to 36 and mime, but they're not in
/usr/share/info itself.  But that doesn't seem to stop C-h i finding
this stuff ...

I frob my .bash_profile to include /usr/share/info/emacs-21/ in
INFOPATH and login on a random console to check this solves the
problem; it does, but now my .bash_profile will need edited every time
I upgrade emacs, which I'll naturally forget to do until the next time
C-h C-f fails on me.

I frob .bash_profile to simply not set INFOPATH at all; that also
works, but I'll have to fall back on the above to access any info
pages I install in my personal filespace.

I remember some of TeX's paths supporting "if the path variable ends
in : then TeX (? kPathSearch ?) implicitly appends all the places it
would have searched if you'd left the path variable unset", so try
setting INFOPATH back to its original value, but with a trailing : -
to no effect; emacs hasn't borrowed this [really really nice] idiom
[that I *really* wish more software would use] off TeX.

I comment out my setting of INFOPATH.  Back in this emacs session, I
M-x setenv <return> INFOPATH <return>
/usr/share/info:/usr/share/info/emacs-21/:/usr/info <return>
and have another go.  No luck.  M-x getenv reports that setenv worked,
so I guess C-h C-f is using a cached value - ah, yes - some rummaging
reveals Info-directory-list.  One
(setq Info-directory-list
      '("/usr/share/info" "/usr/share/info/emacs-21" "/usr/info"))
later the problem is solved; C-h C-f knows about backward-word.

For INFOPATH to be useful, the user's login script needs to be able to
specify only what's to be added to it, without hard-coding the system
default.  If the system's /etc/profile (or equivalent, per shell)
were to set INFOPATH to encode its default, users would be able to
adjust it sensibly; but then the debian emacs package would have to
edit /etc/profile, or /etc/profile would need to source each file in a
system directory set up for packages to put their environment config
into.  Otherwise, the user has to maintain an independent login script
on each machine - no re-use via cvs or more local networking.  This is
not fatal, but it is inconvenient.

The other alternative is for the user to specify INFOPATH entries
inside their .emacs (or stuff it loads) via Info-directory-list.  This
effectively makes INFOPATH redundant: it has to be unset for the list
to be suitably initialised to its default.  The shell provides quite
nice tools that let me (for instance) set INFOPATH to list `every
info/ subdirectory of a directory whose bin/ subdirectory is in my
PATH' (and, at least for anyone who hops among machines much, PATH
itself may be somewhat dynamically computed): but that has to be given
up as a way of initialising Info-directory-list, if INFOPATH must be
unset; and I'm not sure how to go about `snip this string at each :
then, for each fragment that ends in /bin, replace that /bin with
/info and see whether the fragment now names a directory - if so, add
that directory to the list' in elisp ... and such a solution is only
of use for info within emacs, not (say) the command-line info client.

These issues, though minor for most folk, for any given path, recur
for all software that uses an environment variable to specify a list
of directories to search.  One way to deal with them, universally, is
to interpret an `empty' entry in the path (leading or trailing :, or a
use of :: part-way through) as `insert defaults here'.  There are, no
doubt, cases where one should have reservations about this; but
INFOPATH, at least where the system default involves some
version-dependencies, is a prime candidate for applying the idiom.

It is hard to see any problem, least of all anything harmful, arising
from the inadvertent inclusion of the system default (e.g. when
someone's script says INFOPATH="myinfodir:$INFOPATH" without checking
whether the path was set previously; but they probably did expect to
get the system default in this case, and any problem it presents is
readily enough fixed) and the present arrangement provides a strong
disincentive to setting INFOPATH.  That, in turn, increases the
barrier to entry for folk considering using info as the format in
which to write their documentation - they'd have to put it in one of
the system default directories or most users wouldn't be able to read
it without jeopardising their ability to read the system info pages.

Anyway:
  * C-h C-f can fail to see things C-h i sees - not good.

  * it would be nice if INFOPATH (and, indeed, other paths -
    e.g. EMACSLOADPATH) were to support some semantics for `and all
    the places you would have searched if this was unset'

I have solved my problem well enough for my present purposes, but
maybe I've persuaded you that some improvement is possible !

Recent input:
k <return> C-x o C-x k <return> M-> M-< C-w C-x k <return> 
C-x o M-< C-y M-> M-x r e n <tab> b <tab> <return> 
M-p M-p M-p M-p M-p M-p M-p <return> C-x o q C-h i 
C-x o C-h f b a c k w a r d - w o r d <return> C-x 
o C-x k <return> C-x o C-x C-f b a c k w <tab> C-h 
C-f b a c k w r <backspace> a r d - w o r d <backspace> 
<tab> <return> M-x M-p M-p M-p M-p M-p M-n <return
>

Recent messages:
Wrote /home/eddy/work/qt-desktop/linux/hotlist/Makefile
(No files need saving)
Mark set
Press C-c C-c when you are done editing.
Enter a change comment.  Type C-c C-c when done
Checking in /home/eddy/work/qt-desktop/linux/hotlist/Makefile...done
Making completion list...
Mark set [6 times]
Type C-x 4 b RET to restore the other window.  C-M-v to scroll the help.
Quit
Info-find-node: Info file emacs does not exist