[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Contributing to Emacs Development

> Date: Sat, 11 Nov 2000 21:41:34 -0600
> From: srivasta@acm.org
> 	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.

My feeling was that solving these problems might indeed require some
changes in Texinfo (that's why I said I didn't believe in
back-compatible solutions).  If you have specific suggestions, perhaps
we could hear them.

>  perhaps automagically providing changebars between versions as well

This is IMHO a separate feature.  It is not easy to implement (simple
diffs will not do, because many changes correct only stylistics or
typos), but if you have ideas, please tell what they are.

> * 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.

The above will work, but only for bundled Info files.  For example, if
you choose emacs-20/emacs, all the other Emacs-related manuals, such
as `message', `gnus', etc. will come from that directory.  However,
what happens when the user installs a newer Gnus, downloaded from the
Gnus CVS?  I expect that user to want to get that newer Gnus' manual
instead of the one which came with Emacs.  Unless the user replaces
the manual supplied with Emacs with the newer version, the above
solution will not DTRT.

>  I thik that C-h C-f should ask for a versioned emacs info file

If we agree on the subdirectory solution, C-h C-f will work, I think.

>  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? 

Please suggest a solution.

> 	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.

Why isn't subdirectories a better way?  Since the Info reader already
looks first in the directory where the current Info file lives, it
will see the correct file first, right?  With subdirectories, the only
problem left to be solved is the case where someone installs a newer
version of a package, such as Gnus, which came bundled with Emacs.

> 	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.

Sorry, I Don't understand: which proposal are you talking abut here?
Is it the post-processing of Info files?

Reply to: