Re: Intention to re-write /usr/sbin/install-info
>>>>> "Ben" == Ben Gertzfield <firstname.lastname@example.org> writes:
Ben> I just took a look at the code for install-info, and a peek
Ben> at all the bugs that have been reported on it, and have
Ben> decided to re-write the code entirely.
Sounds good. I've been working on the `info.el' program in
XEmacs-20.3 beta. I've merged some things from Emacs-19.34 into it.
Here's the NEWS entry for my changes.
** Info "dir" functionality merged from Emacs-19.34
All of the directories on `Info-directory-list' will be searched for
"dir" files, which may be full fledged Info files containing subnodes
as well as menus. They are merged to become one directory, with menus
in like-named subnodes being coalesced from the several "dir" files.
"localdir" files are looked for too, secondary to "dir"'s. If there's
no "dir" in a directory, a "localdir" will be looked for. There can
be one of either "dir" or "localdir" in each of the directories in
`Info-directory-list', which is initialized from `Info-default-
directory-list', which you may customize through the Options menu.
The first directory specified in `Info-default-directory-list' should
contain a "dir" file that will become the toplevel dir which the
others will be merged into. A "localdir" may optionally contain a
'* Menu:' section, or just entries like those in a menu section, but
no subnodes or info header. You can see what I'm talking about if you
view the "dir" file that comes with XEmacs. It has a header section
that should not be in a "localdir" file. The "localdir" should look
like the `buffer-substring' of XEmacs' stock "dir" from just below
"* Menu:" to the end of the file, optionally also containing the
"* Menu:" line.
The contents of each "localdir" file will be inserted into the
toplevel "dir" file replacing a '* Locals:' line, OR alternatively,
will insert it below a 'Local*' (that's a regexp) heading line. If
there's more than one "localdir" file, each will either consume a '*
Locals:' line, be catenated to the end of the (dir)Top, or be inserted
under the 'Local' topic header.
There is a new variable, called `Info-additional-directory-list',
which you may customize also, that can contain a list of directories
in which to search for Info documents, but NOT to search in for "dir"
or "localdir" files. This is useful for things like the Calc package,
which likes its info files in its lisp directory. If you put that
directory in the 'additional list', and a menu entry for it in one of
your "dir" or "localdir" files, a click on a menu entry for it will be
able to find the Info file.
XEmacs has "localdir" files, where Emacs uses only "dir" files. The
localdir's are meant for add-on packages' menu entries. With a good
`install-info' script, I think that using normal (dir) files will be a
better solution. Both emacsen should work the same with those now.
Ben> The old code is Perl4-based (not a good thing) and has lots
Ben> of nasty hacks and yucky bugs in it.
Font-lock-mode hates perl4. Everything turns green because of ` and
' marks. It's very frustrating. Cperl mode handles perl5 a lot
better, for sure.
Ben> So, I figure it won't be too much trouble to just re-write
Ben> the whole thing from scratch. There are only a few problems:
Ben> Also, I need to know *exactly what* install-info should
Ben> do. I've searched around a bit, and haven't found this
Ben> information. I can replicate what the current one does, and
Ben> fix all the current bugs, but that's no guarantee it'll be
Ben> perfect. Where can I find this information?
I hope you understand Emacs/XEmacs Lisp well enough to read the code
in `info.el'. That will give you the best idea of what an `install-
info' script should be able to do. I think you should look at the
version in Emacs, as well as the one in the XEmacs-20.3 beta. I can
send you that one if you like, email or SAFT.
I suppose that `install-info' should support the same interface as
the current script, and you should add the ability to place entries
under subnodes of a (dir) file, not just under topic headings of the
"Top" node of it. I'm not sold on the alphabetical under the headings
way of organizing the (dir) either. It's often better to group things
logically rather than lexically.
I've envisioned having a (dir) file somewhere that's got one node,
not named "Top", but having it's own node name. It will end up in the
top (dir) that gets displayed as a menu entry that opens a subnode.
In this way, info files can be installed in a decentralized way. The
emacsen on a site would be site-configured to have those directories
on the `Info-default-directory-list'. That's just one idea, and may
be a dead end. It's never one man's decision.
The current way of doing things will work fine too... which is better
is up for debate. The advantage of decentralizing is that a straight
untar of a thing could update the program and its info, along with the
(dir) in there. Our way has the serious advantage of making it so we
can have separate documentation packages, and install only a things
info files on the machine that carries those, and the binary pack on
the one that carries them.
Perhaps making everything support both schemes is the best way.
We should create a standard list of headings and subnodes, perhaps,
to be added to the policy manual.
Oh, and will you PLEASE, once it's done, send `install-info' to FSF?
 SAFT = `sendfile', Simple Asynchronous File Transfer. It's really
mailto:email@example.com (Karl M. Hegbloom)
Portland, OR USA
Debian GNU 1.3 Linux 2.0.30+parport AMD K5 PR-133