> Add to that a mechanism for building a dir file out of
> snippets that programs can place in a directory,
There are two such contributed programs in the Texinfo source
distribution already. Maybe one of them would suffice?
./util/fix-info-dir and ./util/gen-dir-node. I haven't yet
Manoj Srivastava <[EMAIL PROTECTED]> writes:
> 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
>>"Kai" == Kai Großjohann <[EMAIL PROTECTED]> 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
>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> However, unless something is done to C-h C-f, the information
>> provided would be for the default version.
Eli> Not necessarily. All we need to make sure is that the Info reader
Eli> looks first in the same directory where the current
> From: Jason Rumney <[EMAIL PROTECTED]>
> Date: Sun, 12 Nov 2000 14:11:12 +
>
> "Eli Zaretskii" <[EMAIL PROTECTED]> writes:
>
> > I'd like to avoid using filesystem features such as symlinks, since
> > they are not portable outside Unix and GNU/Linux systems.
>
> Aren't we trying to solve a
"Eli Zaretskii" <[EMAIL PROTECTED]> writes:
> I'd like to avoid using filesystem features such as symlinks, since
> they are not portable outside Unix and GNU/Linux systems.
Aren't we trying to solve a problem with the Debian installation here?
I do not see any reason to complicate things by tryi
On Sat, 11 Nov 2000, [EMAIL PROTECTED] wrote:
> 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
> Date: Sun, 12 Nov 2000 01:58:20 -0600
> From: Manoj Srivastava <[EMAIL PROTECTED]>
>
> The default would be, for most users, to just say info gnus or
> info emacs; and that would lead one to $INFODIR/gnus, et. al. This
> default file shall be a symbolic link managed by the alternatives
>
>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> 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
>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
>> * 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.
>> .
>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> A combination of file names, subdirectories, and a suitable
Eli> $INFOPATH setting might be able to solve this, but I undestand
Eli> that some people don't think messing with $INFOPATH is a Good
Eli> Thing...
Count me amongst
> Date: Sun, 12 Nov 2000 01:32:43 -0600
> From: [EMAIL PROTECTED]
>
> As I explained in another message, yes, an xref in the info
> file of a non default info file may well lead to the default version
> of the target. A correct solution of course would be to make the info
> document syste
Hi,
Please retain a CC to debian-emacsen@lists.debian.org for this
(and other debian packaging issues) so this discussion is not
lost to people on the debian lists.
>>"Eli" == Eli Zaretskii <[EMAIL PROTECTED]> writes:
Eli> I think Kai explained why this will not necessa
> Date: Sat, 11 Nov 2000 21:41:34 -0600
> From: [EMAIL PROTECTED]
>
> 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 i
> From: Miles Bader <[EMAIL PROTECTED]>
> Date: Sun, 12 Nov 2000 09:47:42 +0900 (JST)
>
> 1) Give each version of emacs its own info directory, which is first
> on the search path, and make sure that all info files that are
> emacs-version-dependent get put into this directory. [I thi
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 underlyi
16 matches
Mail list logo
