Re: Info disaster?
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
> Info mode is looking in the files to build a usable `dir'
file.
This would be a bad idea (read: slow) even if the files were not
gzipped. Shouldn't we just list the info files without opening them?
info.el tries to be smart and searching for these lines.
START-INFO-DIR-ENTRY
* sed: (sed). Stream EDitor.
END-INFO-DIR-ENTRY
This helps a lot if you are going to save generated dir
files. Well, I just found a bug. info.el can't handle
multiple entry lines like a2ps.
Or, couldn't XEmacs do the charade *once*, and then cache the
results.
(Yes, I know XEmacs can write out the created `dir' file, but that's
out of the question because I don't have write permissions on
/usr/share/info.)
I agree. Caching would be nice.
You're quite right. I wonder how the standalone info reader gets
away
with it. A little straceing reveals that it never bothers with
/usr/share/info/dir.gz -- it simply reads /usr/info/dir/. Which is
weird, because /usr/share/info/ is supposed to be the canonical Info
location on Debian. It seems, however, that /usr/info/dir happily
indexes the contents of *both* /usr/info and /usr/share/info.
standalone info never creates dir files. It just uses them
if those exist. It seems a bug of info reader that it
doesn't search for compressed dir files after it finds first
one.
This does not sound promising. I haven't changed the default,
and I
suffer this highly problematic behaviour. How can we adapt to the
situation?
You can test these settings until Debian provides correct
/usr/share/info/dir.
(setq Info-additional-search-directory-list '("/usr/share/info"))
(delete "/usr/share/info" Info-directory-list)
I was also frustrated with those unzipping..., but I'm the
only user of my laptop so I just became root and saved dir
file. :-)
--
Yoshiki Hayashi