Re: Contributing to Emacs Development

[srivasta@acm.org]

Hi,

       [I am putting debian-emacsen on this thread, since that is the
       proper forum for discussing debian packaging of emacse and info]

       The nasic problem we are trying to address here is trying to
 support multiple versions of programs with different info files when
 the underlying infrastructure, namely, texinfo, is deficient, in that
 it does not procide any versioning suypport either in the dir file or
 in intrer document links. 

	We can work around a lot of that deficiency, and the proposal
 I submit about using update alternatives for info files for emacsen,
 gnus, psgml, etc. goes a long way towards handling the most common
 cases. But it is not a substitute for fixing texinfo itself. Indeed,
 once we have handled the most common cases, Isuggest we redirect our
 energy to fixing the infrastructure, and making texinfo a fully
 versioned document infrastructure, (perhaps automagically providing
 changebars between versions as well), rather than trying and cobble a
 fix on top of the current implementation.

>>"Miles" == Miles Bader <miles@gnu.org> writes:

 Miles> Perhaps I'm missing something, but using static links via the
 Miles> alternatives mechanism doesn't seem as if it will solve the original
 Miles> problem Eli reported.

	Since I came in to this list recently, I am not sure if the
 correspondence I saw contains the original problem. However: 

	[SNIP C-h C-f leading to the info the default emacs has on a
	 command; which is incorrect if one is runnoing a non-default
	 emacs] 

 Miles>   1) Give each version of emacs its own info directory, which is first
 Miles>      on the search path, and make sure that all info files
 Miles>      that are emacs-version-dependent get put into this
 Miles>      directory.  [I think this will work with non-emacs info
 Miles>      readers, because they never have this implicit dependency
 Miles>      on the `currently running emacs version', so static links
 Miles>      will be ok for them]

	This is the second proposal I put forward. Let me provide an
 updated version:
* 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. I thik that C-h C-f
 should ask for a versioned emacs info file, and the underlying info
 system support this request. Barring that solution, we are left to
 these kludges; and the potential for user confusion.  

 Miles> Am I incorrect?  If so, could you explain in more details how these
 Miles> cases work using your proposed setup?

 	Kai Großjohann bringts up a different issue:

 Kai> I think that won't help at all with the problem at hand.
 Kai> Consider Gnus, for example.  It comes with several info files,
 Kai> viz, gnus.info and message.info.  There are links from one to
 Kai> the other.  Surely the links should be to the right version, ie
 Kai> the Gnus 5.7 info file should point to an older version of
 Kai> message.info than the Gnus 5.8 info file.

	Bingo. Why doesn't info support that out of the box? 

 Kai> Everybody clicking on the link will go to the `message' info
 Kai> file.  If you wanted to provide two versions of Gnus, your info
 Kai> files would need to point to two different `message' info files.
 Kai> Does this in fact happen?

	Indeed. If you are using a non default emacs, then the inter
 document links shall point to the the default version of the target
 document; and that is not the correct one if you are looking up a non
 default version. 

	Short of post processing the generated info files looking for
 links via the Top node, and then substituiting a versioned link (this
 is a kludge), I see no way to do this.

	The way I see it, the proposal accomplishes this:
 a) It allows for multiple versions of programs to be installed and
    used; and the information for the default version is readily
    available, both in emacs and in stand alone versions
 b) Information about commands in emacs, using C-H C-F leads to the
    correct version of the info file, regardless of the fact whether
    one is using the default version or not. 
 c) One can look for information on non-default versions of programs,
    with the caveat that links may lead to the default bversoins of
    the targets. 

	Handle the common cases first, Make the most common cases
 easy, Make the rest possible. I believe we have achieved that with
 this proposal. Making the links point correct needs versioning
 support in the underlying infrastructure.

	manoj
-- 
 Imagination is the one weapon in the war against reality. Jules de
 Gaultier
Manoj Srivastava     <srivasta@acm.org>    <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