[rfc] Implementation of qXfer
Eli Zaretskii
eliz@gnu.org
Fri Jun 23 07:34:00 GMT 2006
> Date: Thu, 22 Jun 2006 16:13:11 -0400
> From: Daniel Jacobowitz <drow@false.org>
>
> On Thu, Jun 22, 2006 at 11:07:50PM +0300, Eli Zaretskii wrote:
> > They are OK, except for this issue with anchors whose names contain a
> > colon: this is against the Texinfo language rules. You might be lucky
> > with a particular Info reader, but there are others out there, and
> > each one of them uses a different method of searching for
> > cross-reference names (some use fixed strings, others use various
> > regular expressions). Using a colon makes them fail in different
> > situations and in different interesting ways.
>
> Do you have a reference for this? I spent a while with the Texinfo
> documentation when I was working on that, and could not find it. Just
> curious.
The Texinfo manual doesn't say that explicitly for anchors. It does
say that for node names:
* Unfortunately, you cannot use periods, commas, colons or
parentheses within a node name; these confuse the Texinfo
processors.
These limitations are due to the syntax of menus and cross-references
where these characters delimit syntactically significant parts of the
reference.
In the section about anchors, there's this text that hints that
anchors and nodes share the same limitations:
Anchor names and node names may not conflict. Anchors and nodes are
given similar treatment in some ways; for example, the `goto-node'
command in standalone Info takes either an anchor name or a node name as
an argument.
I will ask the Texinfo maintainer to add an explicit text about anchor
name limitations.
> > So please let's remove the colons and use some other mnemonic methods
> > to make the xref reflect the packet descriptor.
>
> Blech. Well, I don't know what else to use. I tried using
> qXfer-auxv-read, but it's pretty ugly.
How about "qXfer auxv read" or "qXfer read auxiliary vector"?
> > AFAICS, you just moved the text elsewhere and replaced qPart with
> > qXfer, right? If there are new portions of text, please tell where
> > they are.
>
> No, much of the text is changed; the packet has a different format
> and different replies. I definitely rewrote the Reply: table and
> the paragraphs right after qXfer:OBJECT:read and qXfer:OBJECT:write.
Well, at least in this hunk the text was not touched:
> -Fields within the packet should be separated using @samp{,} @samp{;} or
> @cindex remote protocol, field separator
> +Fields within the packet should be separated using @samp{,} @samp{;} or
> @samp{:}. Except where otherwise noted all numbers are represented in
> @sc{hex} with leading zeros suppressed.
There are several commas missing in these two sentences.
Anyway, I've read all of your text yesterday, so it's okay with me.
More information about the Gdb-patches
mailing list