[mi, doc] mention escape sequences

[mi, doc] mention escape sequences

[Vladimir Prus]

[-- Attachment #1: Type: text/plain, Size: 507 bytes --]


It does not seem that MI spec ever mentions escape sequence support
(where it's supported) or lack of such support. This patch tries to
fix that. 

Note that parse_escape function supports more than C language escape
sequences, it seems, but given that the function has no comments on
those sequences, and given that manual does not say anything about
that either, I don't feel like reverse-engineering the code to
document the exact rules. "As in C" as sufficient, I think, for MI
manual.

OK?

- Volodya

[-- Attachment #2: escape.diff --]
[-- Type: text/x-diff, Size: 767 bytes --]

Index: gdb/doc/gdb.texinfo
===================================================================
RCS file: /cvs/src/src/gdb/doc/gdb.texinfo,v
retrieving revision 1.504
diff -u -p -r1.504 gdb.texinfo
--- gdb/doc/gdb.texinfo	10 Jun 2008 10:23:53 -0000	1.504
+++ gdb/doc/gdb.texinfo	11 Jun 2008 14:04:34 -0000
@@ -18018,6 +18018,10 @@ list.  Each option is identified by a le
 followed by an optional argument parameter.  Options occur first in the
 parameter list and can be delimited from normal parameters using
 @samp{--} (this is useful when some parameters begin with a dash).
+
+@item
+Within @var{c-string}, all escape sequences allowed by the C language
+are recognized.  Escape sequences are not allowed in @var{non-blank-sequence}.
 @end itemize
 
 Pragmatics:

Re: [mi, doc] mention escape sequences

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Wed, 11 Jun 2008 18:07:25 +0400
> 
> Note that parse_escape function supports more than C language escape
> sequences, it seems, but given that the function has no comments on
> those sequences, and given that manual does not say anything about
> that either, I don't feel like reverse-engineering the code to
> document the exact rules. "As in C" as sufficient, I think, for MI
> manual.

Maybe not all exact rules, but a single example would be good, I
think.  After all ``escape sequences'' is a heavily overloaded term,
even with the "C" qualifier, and without an example, the reader might
be left in doubt.

> Escape sequences are not allowed in @var{non-blank-sequence}.

How do you mean ``not allowed''?  Perhaps you mean ``not
interpreted'', i.e. output verbatim?

Re: [mi, doc] mention escape sequences

[Vladimir Prus]

On Wednesday 11 June 2008 23:06:22 Eli Zaretskii wrote:
> > From: Vladimir Prus <vladimir@codesourcery.com>
> > Date: Wed, 11 Jun 2008 18:07:25 +0400
> > 
> > Note that parse_escape function supports more than C language escape
> > sequences, it seems, but given that the function has no comments on
> > those sequences, and given that manual does not say anything about
> > that either, I don't feel like reverse-engineering the code to
> > document the exact rules. "As in C" as sufficient, I think, for MI
> > manual.
> 
> Maybe not all exact rules, but a single example would be good, I
> think.  After all ``escape sequences'' is a heavily overloaded term,
> even with the "C" qualifier, and without an example, the reader might
> be left in doubt.

Okay, which texinfo markup should I wrap "\r" in?

> 
> > Escape sequences are not allowed in @var{non-blank-sequence}.
> 
> How do you mean ``not allowed''?  Perhaps you mean ``not
> interpreted'', i.e. output verbatim?

Right; I'll adjust the text accordingly.

- Volodya

Re: [mi, doc] mention escape sequences

[Eli Zaretskii]

> From: Vladimir Prus <vladimir@codesourcery.com>
> Date: Thu, 12 Jun 2008 09:05:08 +0400
> Cc: gdb-patches@sources.redhat.com
> 
> > Maybe not all exact rules, but a single example would be good, I
> > think.  After all ``escape sequences'' is a heavily overloaded term,
> > even with the "C" qualifier, and without an example, the reader might
> > be left in doubt.
> 
> Okay, which texinfo markup should I wrap "\r" in?

Use @samp{\r}.