On 6 August 2015 at 03:39, Eli Zaretskii e...@gnu.org wrote:
Date: Wed, 5 Aug 2015 21:16:36 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
Symlinks are less portable than init files.
What
Date: Sat, 8 Aug 2015 09:00:14 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
One idea I had, which could be useful for Windows and other systems
lacking symlinks, is to make an Info file
On 8 August 2015 at 09:32, Eli Zaretskii e...@gnu.org wrote:
problems I foresee are
that indirect sub-file tables have hitherto never contained absolute
paths
Why would it need to, since this is only about renaming the basename
of the Info file, isn't it?
Assuming you were asking about the
Date: Thu, 6 Aug 2015 10:13:59 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: 793...@bugs.debian.org, Texinfo bug-texinfo@gnu.org,
Rob Browning r...@defaultvalue.org, Karl Berry k...@freefriends.org
On 4 August 2015 at 00:10, Norbert Preining prein...@logic.at wrote:
ANyway, I
I implemented an option in the standalone Info browser to search the
subdirectory containing the current Info file when following a
cross-reference to another manual, before searching through the Info
file search path. Emacs Info could have a similar option.
The variable is called
On Thu, 06 Aug 2015, Gavin Smith wrote:
I implemented that yesterday; are you able to run the version from the
development repository?
I have added your patch from yesterday together with the patch
you sent before about having / in info dir files to the
Debian package, and I could follow the
On 6 August 2015 at 10:43, Norbert Preining prein...@logic.at wrote:
But we also have an entry
* Eshell: (emacs-24/eshell). ...
Then I have removed all references but the main to emacs from the
dir file, and retested, but still eshell info was found and loaded.
So yes, it seemed
On 4 August 2015 at 00:10, Norbert Preining prein...@logic.at wrote:
ANyway, I wan to return to the proposal I wrote some time ago and
that was discarded as not working (or unclear):
Change info reader node search method as follows:
* if a node is going to be followed, first search
Date: Tue, 4 Aug 2015 21:20:47 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
A solution that supports inter-manual links, both in Info and in HTML
formats. To do this on a per-user
On 5 August 2015 at 16:06, Eli Zaretskii e...@gnu.org wrote:
Date: Tue, 4 Aug 2015 21:20:47 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
A solution that supports inter-manual links, both in
Date: Wed, 5 Aug 2015 18:09:45 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
Which is why I think having a feature that would transparently replace
foo in an Info file name with
Date: Wed, 5 Aug 2015 21:16:36 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
Symlinks are less portable than init files.
What operating systems don't support symlinks
Windows. (Later
On 4 August 2015 at 14:34, Eli Zaretskii e...@gnu.org wrote:
It would still be better than what we have at the moment, though.
In what way would it be better? I don't see any significant
improvement, just the added complexity.
You could easily install and access multiple versions of manuals
Date: Mon, 3 Aug 2015 23:32:08 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: 793...@bugs.debian.org, Texinfo bug-texinfo@gnu.org,
Rob Browning r...@defaultvalue.org
If you don't care about being able to access renamed files via
cross-references, then the renaming of files to
Date: Tue, 4 Aug 2015 08:10:23 +0900
From: Norbert Preining prein...@logic.at
Cc: 793...@bugs.debian.org, bug-texinfo@gnu.org, r...@defaultvalue.org
lots of mails here, but I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting
On 4 August 2015 at 14:35, Eli Zaretskii e...@gnu.org wrote:
Then there would only be one foo.info manual reachable for
each element in PATH (those other than the first can be accessed with
info --all foo). This means that info foo can only give the manual
for a particular version of foo if
Date: Tue, 4 Aug 2015 15:16:45 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
On 4 August 2015 at 14:34, Eli Zaretskii e...@gnu.org wrote:
It would still be better than what we have at the
Date: Tue, 4 Aug 2015 15:27:51 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Karl Berry k...@freefriends.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org, Rob Browning r...@defaultvalue.org
Suppose there are two emacs installations, one as /usr/bin/emacs,
which is
lots of mails here
Indeed. I'm afraid I can't keep up, so after these short replies, I'm
bowing out of this thread.
I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting to be able to *check* all of them.
I don't
would be useful for install-info to be able to do some transformation,
along with a transformation of the filename. (Karl, please explain why
you think this is a bad idea.)
Having I-I being able to transform dir file entries I have no particular
objection to. I suppose that is the
Date: Tue, 4 Aug 2015 19:55:41 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Karl Berry k...@freefriends.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org, Rob Browning r...@defaultvalue.org
I'm saying that manuals that don't have any executables will be in
trouble.
Date: Tue, 4 Aug 2015 19:51:23 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Rob Browning r...@defaultvalue.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org
On 4 August 2015 at 16:39, Eli Zaretskii e...@gnu.org wrote:
You could easily install and access multiple
On 4 August 2015 at 20:10, Eli Zaretskii e...@gnu.org wrote:
Can you elaborate on what would constitute a complete solution?
A solution that supports inter-manual links, both in Info and in HTML
formats. To do this on a per-user basis, we would need some
environment variable or/and user init
On 4 August 2015 at 16:39, Eli Zaretskii e...@gnu.org wrote:
You could easily install and access multiple versions of manuals
side-by-side, by configuring with --program-suffix. Taking the example
of Texinfo, you could access different versions of the Texinfo manual
with info texinfo-5.0, info
On 4 August 2015 at 16:44, Eli Zaretskii e...@gnu.org wrote:
Date: Tue, 4 Aug 2015 15:27:51 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: Karl Berry k...@freefriends.org, 793...@bugs.debian.org,
Texinfo bug-texinfo@gnu.org, Rob Browning r...@defaultvalue.org
Suppose there are
Date: Mon, 3 Aug 2015 15:16:27 +0100
From: Gavin Smith gavinsmith0...@gmail.com
Cc: 793...@bugs.debian.org, Texinfo bug-texinfo@gnu.org
On 3 August 2015 at 14:22, Gavin Smith gavinsmith0...@gmail.com wrote:
I'm wondering if we can kill two birds with one stone here and get
install-info
On 3 August 2015 at 22:55, Karl Berry k...@freefriends.org wrote:
Perhaps it's naive, but I feel like I might just want a dir like this so
that I can find what I want and don't have to change global state and/or
restart the viewer just to read different versions:
I agree. You can
Perhaps it's naive, but I feel like I might just want a dir like this so
that I can find what I want and don't have to change global state and/or
restart the viewer just to read different versions:
I agree. You can have that now. It does not need new features, so far
as I can see.
Hi Karl, hi all,
lots of mails here, but I still don't see why you are opposing
the idea to have different versions of the same program installed,
and wanting to be able to *check* all of them.
On Mon, 03 Aug 2015, Karl Berry wrote:
If you're globally changing the meaning of the emacs binary,
That doesn't happen, and nobody seems to miss it. If the shell can
avoid a lot of complexity handling multiple versions of programs, I
suspect it may not be necessary for documentation either.
Indeed. Which is why I don't understand why we're having this whole
thread. Sorry. It
I'm wondering if we can kill two birds with one stone here and get
install-info to actually install the Info file as part of the
solution.
I really really really advise against going down that road. -k
From: Rob Browning r...@defaultvalue.org
Date: Sun, 02 Aug 2015 18:35:29 -0500
Karl Berry k...@freefriends.org writes:
Here's what I don't get: suppose there are two versions of Emacs
installed, emacs-x and emacs-y. Presumably Debian (and anyone else) has
some method for the user to
On 3 August 2015 at 14:22, Gavin Smith gavinsmith0...@gmail.com wrote:
I'm wondering if we can kill two birds with one stone here and get
install-info to actually install the Info file as part of the
solution.
So here's an idea. Add a --suffix option to install-info and at the
same time allow
On 3 August 2015 at 01:40, Rob Browning r...@defaultvalue.org wrote:
- There's an easy way to ask specifically for the foo X pages. I
suppose X might be program specific, but all of the values I can
think of right now are of the form N or N.M. (i.e. GCC 5.0, Python
2.7, Python
On 3 August 2015 at 16:21, Eli Zaretskii e...@gnu.org wrote:
I don't see how this would solve the issue at hand. Installation of a
manual is a system-wide action, whereas Rob wanted a way for a _user_
to specify her preferred version(s) of the manual(s) to use at any
given moment.
How the
Karl Berry k...@freefriends.org writes:
As far as I can see, Debian is creating the problem by distributing
two different versions of Emacs at the same time. So it seems to me the
answer should come at the same level: Debian could have two different
directories with the Emacs manuals. Then
On 2 August 2015 at 00:18, Rob Browning r...@defaultvalue.org wrote:
As far as I can see, Debian is creating the problem by distributing
two different versions of Emacs at the same time. So it seems to me the
answer should come at the same level: Debian could have two different
directories
Gavin Smith gavinsmith0...@gmail.com writes:
One observation is that the case with Emacs having many manuals for it
and associated programs is a rare case. Thus the suggestion of having
subdirectories for each Emacs version (/usr/share/info/emacs23,
/usr/share/info/emacs24, etc.) doesn't mean
Karl Berry k...@freefriends.org writes:
Here's what I don't get: suppose there are two versions of Emacs
installed, emacs-x and emacs-y. Presumably Debian (and anyone else) has
some method for the user to choose which one is invoked by just emacs.
Can't that method, whatever it is, also
39 matches
Mail list logo
