Re: Contributing to Emacs Development

[Manoj Srivastava]

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



 Eli> Practical suggestions for this version-awareness are welcome.

 Eli> One solution I have in mind is some way for the user to tell an Info
 Eli> reader explicitly what version of a certain file to fetch, via some
 Eli> variable or command.  This, in addition to putting Info files in
 Eli> version-specific directories, should solve all the possible cases
 Eli> which were raised in this thread, including installation of Gnus on
 Eli> top of a version that came with the latest Emacs distro.

 >> Stand alone viewers are not as easy; (I am averse to the
 >> solution of writing wrapper scripts for each stand alone info viewer
 >> that reorder the info path (info-e20, info-e21, etc)). 

 Eli> I don't see where stand-alone readers don't fit into this scheme.
 Eli> Could you point out the problems with stand-alone readers you have in
 Eli> mind?

        I install, say, emacs 20.7, and I have an $INFODIR/emacs-20.7
 dir. I also have seveal machines, not all of them on the same update
 timetable, so i have emacs 19, and several different version of emacs
 20 on these machines I deal with. (my firewalls get updates fairly
 rarely). I also have several Debian ,achines at work and lient
 locations. I do't always know the versions of emacsen there.

        Now, I install gnus separately on some of these machines. 

        When I say info gnus, I want to see the info on the version of
 gnus that appears in emacs when I say M-x gnus. I want the same thing
 to happen when I say C-h i m gnus<ret>, and so on.

        This is imperative that I get some documentation, and the
 docuimentation correspeonds to the program that comes up when I say
 M-X gnus, whether or not I have installed gnus separately, and
 withoput me having to figure out which version of emacs shall come up
 when I invoke emacs. 
                
        Everything else is secondary.   

        With sub directories for each emacsen, and using update
 alernatives to manage the default versions fo all files, we achive
 most of what we want; the only things I think that shall fail is that
 xrefs always shall go to the default version of the target, and that
 C-h C-f may need some changes to go to the non-default version as
 well. 

 Eli> The only complaint I have about the specific (and the only) Debian
 Eli> system which I sometimes use on fencepost.gnu.org is that C-h C-f is
 Eli> broken there.  I understand the reasons for post-processing Info
 Eli> files, but unfortunately it breaks features which work in a simple
 Eli> single-version installation for the sake of allowing multiple versions
 Eli> for which I personally have no use.  (I'd imagine that
 Eli> fencepost.gnu.org is one machine where there should always be the
 Eli> latest Emacs, and it alone ;-)

        In which case, if we use the solution we have come up with,
 this irritant shall be eliminated; since that single emacs shall be
 the default one, and my proposal makes things always work for default
 versions of programs. 

 >> the info system is trying to be a document management
 >> system for program documentation; perhaps it should borrow some
 >> versioning concepts from formal SGML document management systems? 

 Eli> Could you please elaborate on those concepts, and on how do they
 Eli> pertain to Texinfo?

        Think of them, conceptually, as a combination of version
 control systems and a system for mainataining versioned dependencies
 analogous to ldconfig. texinfo only needs to vorrow the ldconfig
 analog. Each texinfo file needs to have a version; and each file
 generated from this needs to have that version embedded in the file
 name; xrefs need to have an optional version parameter for links that
 should be versioned. And install-info (or a new, separate, program)
 should trawl through the system updating symbolic links like ldconfig
 does.

        Add to that a mechanism for building a dir file out of
 snippets that programs can place in a directory, and debian can dump
 its confusing install-info script that behave nothing like the
 upstream install-info command (which debian does not need for its
 packages). But that is a totally different wishlist ;-)

        manoj
-- 
 Oh, wow!  Look at the moon!
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