>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> I think the interest is there. IIRC, this was discussed about a year
Eli> ago, perhaps even with you.
Eli> My personal recollection from those past discussions is that the
Eli> alternative I liked best was to make sure the list of the directories
Eli> searched by the Info browser is such that it finds the right files
Eli> first. Perhaps that means we need to modify the search path as each
Eli> manual is loaded into the browser, instead of initializing it only
Eli> once.
Hmm. I am not sure I understand.
Let us see what kinds of scenarios exist for info files.
a) info files for packages contained within an emacs flavour/version.
b) An add on package that does not conflict with any built in
package, but may or may not be installed on all the
flavours/versions of emacs installed on the machine
c) An add on package that does conflict with a built in package, but
is only installed on a subset of the emacs variants installed on
the machine.
The hard part is the info files provided by packages in
category c. If I understand your solution, it entails creating a
separate directory for each of these categories:
emacs20/add-on
emacs20/builtin
emacs21/add-on
emacs21/builtin
xemacs20/add-on
xemacs20/builtin
xemacs21/add-on
xemacs21/builtin
The add on packages themselves are responsible to see that
they are included in the proper directory, since only they know which
flavour/version they ought to be installed for.
The info files in the add on directories may be duplicated if
the add on package is install-able in more than one (but perhaps not
all) flavours of emacs installed locally.
How does all this interact with the top level dir file?
======================================================================
The Directory File `dir'
------------------------
For Info to work, the `info' directory must contain a file that serves
as a top level directory for the Info system. By convention, this file
is called `dir'.
======================================================================
Now, each dir file needs to be different for each emacs
flavour+version (unless I am missing something). And in each such dir
file, the new, add-on packages need to be inserted and removed from
the top of the dir file, which makes browsing the top level file
somewhat yucky.
Hmm. The top level dir in my current emacs seems to be
organized in sections, alphabetically. So it would seem that in each
section, we need a built in sub part and an add-on sub part, the
add-on sub part coming first.
Somehow, this does not seem cleaner than the emacs.d solution
(though it is not any worse either).
This, of course, still does not take into account multiple
versions of an add on package coexisting.
Would be really nice if we could have Pterodactyl Gnus
packaged for emacs20 and Oort Gnus packaged for emacs21. Thinking
about that, I think I can see how I can manage the elisp files for a
Debian emacs-lisp package under the current policy, and the multiple
directories approach would allow me to manage the info files as well.
manoj
--
Kids, the seven basic food groups are GUM, PUFF PASTRY, PIZZA,
PESTICIDES, ANTIBIOTICS, NUTRA-SWEET and MILK DUDS!!
Manoj Srivastava <[EMAIL PROTECTED]> <http://www.debian.org/%7Esrivasta/>
1024R/C7261095 print CB D9 F4 12 68 07 E4 05 CC 2D 27 12 1D F5 E8 6E
1024D/BF24424C print 4966 F272 D093 B493 410B 924B 21BA DABB BF24 424C
