Re: Contributing to Emacs Development

[Manoj Srivastava]

>>"Eli" == Eli Zaretskii <address@hidden> writes:

 >> * Emacs: (emacs)      .       The extensible self-documenting text  editor.
 >> * Emacs-20: (emacs-20/emacs). The extensible self-documenting text  editor.
 >> * Emacs-21: (emacs-21/emacs). The extensible self-documenting text  editor.
 >> . update-alternatives is used to provide the default info file entries.
 >> 
 >> Then each emacs version can have a modified into path. I am
 >> not sure I really like this -- since C-C C-f leads to a different
 >> location than just C-h i and Menu Emacs does.

 Eli> The above will work, but only for bundled Info files.  For example, if
 Eli> you choose emacs-20/emacs, all the other Emacs-related manuals, such
 Eli> as `message', `gnus', etc. will come from that directory.  However,
 Eli> what happens when the user installs a newer Gnus, downloaded from the
 Eli> Gnus CVS?  I expect that user to want to get that newer Gnus' manual
 Eli> instead of the one which came with Emacs.  Unless the user replaces
 Eli> the manual supplied with Emacs with the newer version, the above
 Eli> solution will not DTRT.

        well. That is one way of doing it, and you have put your
 finger on the flaw. 


        Alternately, if we settle on the solution of the emacsen
 creating a separate sub directory for each version, BUT using update
 alternatives to maintain a set of files in the top level info dir
 that point to the files for the current default alternative; we can
 have the best we solution we can offer under the circumstances.

        The default would be, for most users, to just say info gnus or
 info emacs; and that would lead one to $INFODIR/gnus, et. al. This
 default file shall be a symbolic link managed by the alternatives
 mechanism, so installing a new gnus shall do the right thing. 

        If you asked for a specific emacs version, and you then follow
 the link to gnus there, I presume you are seeking information about
 the bundled gnus.


        However, unless something is done to C-h C-f, the information
 provided would be for the default version. 

        If we have each emacsen re-order the Iinfo-path, then we shall
 fail to see the info for indepndently installed packages, like
 gnus. I don't like that. 

        For the majority of our installed base, the default emacsen
 and the default, independtly installed emacs lisp packages should be
 the most readi;y available, with no extra work by the user. Using sub
 dirs and update-alternatives the problem has come down to extra work
 to follow xrefs in non-default documentation. 

        Incidentally, the flavour of emacs lisp packaging for Debian
 has been strongly influenced by th fact that majority of our target
 installations are either personal desktops, where there are very few
 (usually one) users, or they are server machines, which tend not to
 have very many emacs lisp packages installed. So a number of
 packagfes insert themselves automatically in the site-wide emacs
 intialization process (this should give you a flavour of the type of
 customization users tend to expect on a debian box). 


 >> I thik that C-h C-f should ask for a versioned emacs info file

 Eli> If we agree on the subdirectory solution, C-h C-f will work, I think.

 Eli> Please suggest a solution.

        At the time of generation of files from teh texinfo files, one
 needs to extract a version based string from there; and all files
 produced have this version number embedded in them. An xref listing
 should either be generic (look at the latest make insormation), or be
 version stamped: look at the message file with this version number).

        We then need a mechanism of updating the ``generic'', or
 default, version of the info file (and we may need to do this only
 for the top level info file for each package, since all files are
 generated with version info embedded in them). 

        The model I am basing this on is the one used by shared
 libraries on a UNIX system. We have patterns that deal with versioned
 files, and simultaneous insallation of multiple versions of a shared
 library using symbolic links and everything. 

        We would have to modify install-info to handle manipulation od
 the symbolic links, like ldconfig does. 

        manoj
-- 
 "You can't make a program without broken egos."
Manoj Srivastava   <address@hidden>  <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