Re: Info disaster?
Hrvoje Niksic <hniksic(a)iskon.hr> writes:
Daniel Pittman <daniel(a)danann.net> writes:
> On 07 Jan 2000, Hrvoje Niksic <hniksic(a)iskon.hr> wrote:
>
> > I've been seeing this for quite a while, but I haven't had time to do
> > anything about it, so I kinda hoped it'd go away. The thing is, when
> > I first start info, I see these messages (in chronological order):
>
> [...]
>
> > What the <beep> is it?
>
> 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?
Then we would get an info top-node which would look less nice. I
think the files are opened because most of them contain information
like
INFO-DIR-SECTION World Wide Web
INFO-DIR-SECTION GNU Emacs Lisp
START-INFO-DIR-ENTRY
* Emacs/W3: (w3). Emacs/W3 World Wide Web browser.
END-INFO-DIR-ENTRY
at the top, which XEmacs extracts and displays in the info Top-node:
Info files in /home/mike/emacs/w3-cvs/texi/:
* Emacs/W3 FAQ: (w3-faq). FAQ for Emacs/W3 World Wide Web browser.
* Emacs/W3: (w3). Emacs/W3 World Wide Web browser.
If the info file doesn't contain this extra information about the
info-dir-entry, XEmacs creates somethink like this in the Info
Top-node:
Info files in /home/mike/emacs/ilisp-5.9.3/docs/:
* Ilisp:: [No description available]
This could be done without opening the files, but it looks less nice.
Or, couldn't XEmacs do the charade *once*, and then cache the
results.
I think it does. When I first use info-mode in an XEmacs session, I
have to wait a few seconds while XEmacs creates the info Top-node, but
it does that only once. Subsequently the info Top-node comes up
immediately.
> Debian, bless their little soul, have `dir.gz' in the
directory with
> nothing listed.
You're quite right. I wonder how the standalone info reader gets
away
with it.
The standalone info reader seems to need a correct dir-file.
I think XEmacs ignores a dir.gz file anyway. Comment near the top of info.el:
;; Note: "dir" and "localdir" files should not be compressed.
I fell into this trap a few times after doing a `gzip *' in my info
directory.
> The variable that controls it is:
>
> (defcustom Info-auto-generate-directory 'if-missing
> "*When to auto generate an info directory listing.
> Possible values are:
> nil or `never' never auto-generate a directory listing,
> use any existing `dir' or `localdir' file and ignore info
> directories containing none
> `always' auto-generate a directory listing ignoring existing
> `dir' and `localdir' files
> `if-missing', the default, auto-generates a directory listing
> if no `dir' or `localdir' file is present. Otherwise the
> contents of any of these files is used instead.
> `if-outdated' auto-generates a directory listing if the `dir'
> and `localdir' are either inexistent or outdated (touched
> less recently than an info file in the same directory)."
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?
I don't feel this as problematic. On my Pentium 300 MHz at home it
causes a delay of only 4 seconds when doing `M-x info' the first time.
Subsequent accesses are instantaneous. On some old HP-UX and Sun
workstations at work, doing `M-x info' the first time is in the order
of 10 seconds. But even that doesn't bother me much, as don't exit
XEmacs often.
I did even set `Info-auto-generate-directory' to `always', because
that guarantees that I always see the full listing of all info files.
At home I have the option to create a correct `dir' file, but at work
I don't have permissions to do that. And the existing `dir' files
usually contain only a subset of the available info files, because the
sysadmin didn't care. Thus, unless I set
`Info-auto-generate-directory' to `always', I would miss many entries
in the Info Top-node. Better wait a few seconds than getting
an incomplete listing.
Mike
--
Mike Fabian <mike.fabian(a)gmx.de> <mike(a)nozomi.rhein-neckar.de>