From: Eli Zaretskii <eliz@gnu.org>
To: gdb-patches@sourceware.org
Subject: Re: [rfc] Implementation of qXfer
Date: Fri, 23 Jun 2006 07:34:00 -0000 [thread overview]
Message-ID: <u64isba08.fsf@gnu.org> (raw)
In-Reply-To: <20060622201311.GA22171@nevyn.them.org> (message from Daniel Jacobowitz on Thu, 22 Jun 2006 16:13:11 -0400)
> 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.
next prev parent reply other threads:[~2006-06-23 7:34 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-06-22 3:32 Daniel Jacobowitz
2006-06-22 20:07 ` Eli Zaretskii
2006-06-22 20:13 ` Daniel Jacobowitz
2006-06-23 7:34 ` Eli Zaretskii [this message]
2006-07-05 19:15 ` Daniel Jacobowitz
2006-07-12 18:51 ` Daniel Jacobowitz
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=u64isba08.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=gdb-patches@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox