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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> <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
