From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23856 invoked by alias); 12 Nov 2005 23:07:13 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 23282 invoked by uid 22791); 12 Nov 2005 23:07:11 -0000 Received: from zproxy.gmail.com (HELO zproxy.gmail.com) (64.233.162.203) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Sat, 12 Nov 2005 23:07:11 +0000 Received: by zproxy.gmail.com with SMTP id l1so1003671nzf for ; Sat, 12 Nov 2005 15:07:09 -0800 (PST) Received: by 10.37.12.41 with SMTP id p41mr1696998nzi; Sat, 12 Nov 2005 15:07:08 -0800 (PST) Received: by 10.37.2.35 with HTTP; Sat, 12 Nov 2005 15:07:08 -0800 (PST) Message-ID: <8f2776cb0511121507s401c9bb0xe4faa8ca9dd89680@mail.gmail.com> Date: Sat, 12 Nov 2005 23:07:00 -0000 From: Jim Blandy To: Eli Zaretskii Subject: Re: Formatting of packet descriptions in GDB manual Cc: gdb@sources.redhat.com In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Content-Disposition: inline References: <8f2776cb0511111624h4d646cd9i1f86824c5edc613f@mail.gmail.com> <8f2776cb0511120047y50b3a273pe17ddd5c53342be1@mail.gmail.com> X-SW-Source: 2005-11/txt/msg00240.txt.bz2 On 11/12/05, Eli Zaretskii wrote: > > I tried that first --- but notice that each @item has explanatory text > > after the packet, like "--- remove hardware breakpoint". > > This is a @table, so that text should be in the next line, not on the > @item line. In many cases, this text is redundant anyway, since what > follows the @item line repeats the explanation. Bless your heart. That's what I actually wanted to do, but not badly enough to bother picking a fight over it. > Because each individual character might be of some importance, > mnemonic if not anything else. But that's a guess, I really don't > have a good answer for this question. I just see our job as defining a syntax. There's no tokenization going on here; those characters must appear in that exact sequence. > Perhaps we should use blanks between those @var's, but explain in the > text that there shouldn't be blanks in the real packet, and give an > example to demonstrate that BLANKS??? What's WRONG with you??? Of course --- that'd work perfectly.