Re: Contributing to Emacs Development

[Manoj Srivastava]

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


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

 Eli> Not necessarily.  All we need to make sure is that the Info reader
 Eli> looks first in the same directory where the current Info file (the one
 Eli> which you were browsing when you pressed C-h C-f) lives.  The
 Eli> stand-alone Info reader already does that, and I'm almost sure Emacs
 Eli> does that as well (if not, it can be easily changed so it does).

 Eli> If I'm right, then putting different versions into subdirectories will
 Eli> not break C-h C-f, whether or not you use the default `emacs' file.

        good.

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

 Eli> Not necessarily.  A package that is likely to be updated
 Eli> asynchronously, even though it comes bundled, should adopt the
 Eli> same version-related directory structure as Emacs.  Thus, you
 Eli> will have gnus-5.7/gnus, gnus-5.8/gnus, etc., and the default
 Eli> `gnus' will point to one of them.

        Hmm. This is more complicated than it appears at first thought.
 a) It is hard to know a priori which package is likely to be updated
    asynchronously.  Gnus wasn't distributed separately for a long
    time; and things like cc-mode or calc may appear as separate
    packages in the future. Debian policy can't be quite this
    ambiguous, unfortunately.
 b) The only way this works is of we yank gnus out of the versioned
    path of each emacs, and install it in its own versioned
    directory. (else the version of gnus in the dir that is foremost
    in the info path shall always be the one preferred by the info
    rowser) That puts a burden on the emacs packaging, since emacs
    comes with so many different info documents (and the versions of
    each need to be tracked separately); this is a bit much for policy
    to demand, unless there were a straigforward way to determine the
    version of the program programmatically)
 c) However, if we yank gnus out of the sdame directory, then you lose
    the ability to simply go look for the information on the gnus that
    came bundled in with emacs -- you now need to know version
    numbers, since there is no gnus in the same directory, any xref to
    Gnus shall lead you to the default version. 

        So xrefs to independently packaged programs are still a problem.

 >> We would have to modify install-info to handle manipulation od
 >> the symbolic links

 Eli> I'd like to avoid using filesystem features such as symlinks, since
 Eli> they are not portable outside Unix and GNU/Linux systems.  We could
 Eli> simulate symlinks via some new feature in the DIR file.  We almost
 Eli> have the infrastructure for that, in the indirect tag tables.

        Umm. I am not conversant with theis mechanism. However,
 wearing the hat of a debian developer, I can indeed use and exploit
 symbolic links until a general solution is crafted.

        manoj
-- 
 I don't understand you anymore.
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