Re: Contributing to Emacs Development

[srivasta]

Hi,

        Please retain a CC to address@hidden for this
        (and other debian packaging issues) so this discussion is not
        lost to people on the debian lists. 

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

 Eli> I think Kai explained why this will not necessarily work.  An
 Eli> xref like (message)Foo will go to the file `message' in the
 Eli> default Emacs's info directory, not in Emacs 21's info
 Eli> directory.  Imagine the case where the node Foo doesn't even
 Eli> exist in the file `message' that came with Emacs 20 (that's a
 Eli> real-life example, since message.texi got reworked for Emacs
 Eli> 21).

        As I explained in another message, yes, an xref in the info
 file of a non default info file may well lead to the default version
 of the target. A correct solution of course would be to make the info
 document system version aware; a work around inside emacs is giving
 each emacsen a separate info dir, and re ordering the info path. 

        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> It's quite possible that I misunderstood; if so, I apologize for being
 Eli> dense.  

        The misunderstanding was on my part; I mistook the links to
 mean symbolic links in the file system, not xref links between
 texinfo documents.

 Eli>   I still don't see how different versions running
 Eli> simultaneously could cause an Info reader to go to the correct file in
 Eli> each case, given a cross-reference, when the information about the
 Eli> default `emacs' is recorded globally in the file system.

        Then this is an ``upstream'' problem inherent with the info
 system itself; and debian policy can only do so much to address it. 

        As I said, we have a method of handling the most common
 case. We make the info browsing of the non-default emacs version
 possible (with a caveat for xrefs). 

        We'll be happy to listen to a solution for the remainder of
 the cases; however, I do believe this is not something to be handled
 at the packaging level; but it is a design issue with texinfo system
 as a whole. 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? 

        Incidentally, what is supposed to be the general solution, ie,
 for non Debian systems? How are multiple versions of programs
 providing documentation in info formats handled? If there is a
 solution that shall be available, perhaps debian should adopt that,
 rahter than creating a home brew solution?

        manoj
-- 
 language is a virus from outer space and hearing your name is better
 than seeing your face. wm. burroughs, as paraphrased by laurie
 anderson
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