Re: Contributing to Emacs Development
>>"Eli" == Eli Zaretskii <email@example.com> 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
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
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
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 ;-)
Oh, wow! Look at the moon!
Manoj Srivastava <firstname.lastname@example.org> <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