emacs-devel
[Top][All Lists]
Advanced

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

Re: Contributing to Emacs Development


From: Manoj Srivastava
Subject: Re: Contributing to Emacs Development
Date: Sun, 12 Nov 2000 11:16:29 -0600
User-agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.0.90

>>"Kai" == Kai Großjohann <address@hidden> writes:

 Kai> One way to achieve the desired goal would be for Debian to patch the
 Kai> *.texi files before building the info files.  The patched *.texi files
 Kai> should include links to correctly versioned file names, rather than
 Kai> the generic file names.

 Kai> This could be made easier by defining a variable in the preamble of
 Kai> the *.texi file which points to the correct targets, then use that
 Kai> variable.  Then the standard distribution could use the variable, and
 Kai> the Debian patch to change the variable value would be trivial.

        Umm. I think a hint from the authors would be nice, and
 indeed, in the long term, the way to go. It would also be nice if
 these varibales can be given values on the command line that over
 ride the values embedded in the file (think makefile vars)

 Kai> Of course, this means that someone has to think about the target
 Kai> of the link.  For example, suppose that in the Emacs info file
 Kai> there is a link to the Gnus info file which says `Use Gnus for
 Kai> reading news'.  Then we probably want the link to point to the
 Kai> default Gnus version, rather than the one that comes with Emacs.
 Kai> But for links between the Gnus and the Message info files, the
 Kai> version should be retained.

        This is where ahint from the authors would come in
 handy. Perhaps an addendum to the arguments of the xref directive? My
 point is, in the documents where an exact vesioned link is required,
 the author is fully aware of the tight linkage, and can easily
 provide information to xref about the version. 

 Kai> Whee.

 Kai> I think that the most difficult part of the solution is to decide
 Kai> where each link should point to.  Then, implementing this decision is
 Kai> a simple matter.

        I have a proposal. If we agree on a naming convention for the
 generated info files, and info files have a version embedded in the
 name, then we can just let info find us the correct versioned target
 from the info path. Of course, this requires either
 a) link from the versioned name to a non versioned name, and a
    ldconfig analog
 b) a non versioned copy of the versioned file name on OS's that do
    not support symbolic links
 c) the dir mechanism that I am not cognizant of, which may help one
    locate both a versioned file name and a non versioned file name.

        manoj
-- 
 Sic transit gloria Monday!
Manoj Srivastava   <address@hidden>  <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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]