Re: Contributing to Emacs Development

[srivasta]

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

 Eli> [Note that I've redirected this discussion to the development list.]
 >> From: address@hidden
 >> Date: Fri, 10 Nov 2000 23:36:30 -0600

 >> I think we are going to have to consolidate the primary info
 >> directory on Debian into /usr/share/info; and use update-alternatives
 >> for major subcomponents for which various versions may simultaneously
 >> co-exist (emacs 19, 20, and 21; native Gnus for each of these, as
 >> well as the stand alone Gnus package, etc).

 Eli> This problem is relevant to all Info browsers, not only to Emacs,
 Eli> since all Info readers must be able to find the files.

        
        And using update alternatives, they can. Please note that my
 proposal (which is quite inchoate here, and has not yet been
 proposed to the debian-emacsen mailing list) does not actually
 involve emacs at all. The dir file shall say:
* Emacs: (emacs).      The extensible self-documenting text editor.
* Emacs-20: (emacs-20).      The extensible self-documenting text editor.
* Emacs-21: (emacs-21).      The extensible self-documenting text editor.

        And emacs shall be pointed to by the current update
 alternatives candidate. This can be a trifle messy, since all 32 info
 files may need to be modified, but we can work around that, too, by
 perhaps

* Emacs: (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.

        And the directory emacsis the one which is handled by update
 alternatives (or similar mechanisms, should update alternatives fail
 to work for dirs). So you get the curent default Emacs under the menu
 name Emacs; and you can still access particular versions using
 alternate menu names.

 Eli> Several Info features currently look for fixed file names, so renaming
 Eli> Info files, as in emacs-e20, breaks these features.  One example of a
 Eli> feature that's currently broken on Debian is "C-h C-f".

        Hmm. This is not an issue for the first (messier) proposal,
 but is for the second one above.

 Eli> We need to find a solution that will work in all Info readers,
 Eli> preferably without requiring any changes in those readers, for
 Eli> back-compatibility with old readers (although I think this goal is
 Eli> probably all but impossible to achieve).

        You are being far too perssimistic. I think a wrapper around
 update alternatives would make this trivial for packging emacsen on
 Debian. 

 Eli> It looks like such a solution would need to be based on fixed
 Eli> alternate file names, because some Info readers, such as the
 Eli> stand-alone one that's part of Texinfo, are not flexible enough
 Eli> to support anything else.

        If we do use update alternatives, any info browser, including
 emacs, should be totally unaware that the file name has changed under
 it. 

 >> Actually, knowing what emacs 21 contains may help to refine
 >> these policies.

 Eli> What do you want to know?  There are no major changes in the
 Eli> packaging.  A few new packages are now bundled (Eshell, WoMan,
 Eli> Ebrowse) and have their own manuals.

        Being able to produce not-for-distribution-test packages for
 emacs21 would be nice (I must confess, beiung able to pre-test emacs
 is one of the perks of this task)

        manoj
-- 
 Humor in the Court: Mrs. Smith, do you believe that you are
 emotionally unstable? I should be. How many times have you comitted
 suicide? Four times.
Manoj Srivastava     <address@hidden>    <http://www.golden-gryphon.com/>
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