From: Phil Muldoon <pmuldoon@redhat.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: gdb-patches@sourceware.org
Subject: Re: [python][patch] Add GDB Parameters functionality
Date: Tue, 27 Apr 2010 19:25:00 -0000 [thread overview]
Message-ID: <4BD73A07.7020706@redhat.com> (raw)
In-Reply-To: <83wrvsyelz.fsf@gnu.org>
On 04/27/2010 06:44 PM, Eli Zaretskii wrote:
>> +@item PARAM_STRING
>> +The value is a string. When the user modifies the string, any escapes
>> +sequences are translated and encoded by @value{GDBN}.
>
> I asked to say something about this translation, or provide an
> example.
I'm just not sure what to say other than GDB will translate and encode
any escape sequences in the string. In fact, 'encoded' will probably
just do here without the 'translated' verb - it seems redundant with
the new encoded text. I think that is clearer. How about that with a
cross-reference to encoding (pxref{Character Sets})?
>> +@item PARAM_FILENAME
>> +The value is a filename (a string). This value is has to be a valid
>> +filename. ^^
>
> The "is" part is probably redundant. Also, what does it mean "a valid
> filename"? Does it have to exist, for example? If not, what makes a
> file name "invalid"?
I looked a little deeper at this. There is no validation (I was
initially wrong, apologies). Furthermore, it does not have to be a
valid filename at all -- just a string. Validation is presumably
offloaded to the Parameter to check. Anyway, it is a simple
string. The classification of Parameter type in these cases is purely
to do with how completion works -- if the user chooses to use
completion. So 'set foo somefil<tab>' will complete looking for
filenames:
Eg:
(gdb) set logging file ~/log<TAB>
log.txt log2.txt
Whereas for a Parameter with the type PARAM_BOOLEAN (like set verbose)
it would complete like so:
(gdb) set verbose o<TAB>
off on
Now that being said, I'm a little stumped how to explain all of this
within the context of these parameter types. Do you have any input
here?
Cheers
Phil
next prev parent reply other threads:[~2010-04-27 19:25 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-04-26 13:19 Phil Muldoon
2010-04-26 17:56 ` Eli Zaretskii
2010-04-27 12:26 ` Phil Muldoon
2010-04-27 17:45 ` Eli Zaretskii
2010-04-27 19:25 ` Phil Muldoon [this message]
2010-04-27 19:36 ` Eli Zaretskii
2010-04-27 20:05 ` Phil Muldoon
2010-04-28 2:59 ` Eli Zaretskii
2010-04-28 6:28 ` Phil Muldoon
2010-04-28 9:18 ` Phil Muldoon
2010-04-28 17:15 ` Eli Zaretskii
2010-04-28 20:31 ` Phil Muldoon
2010-04-29 3:06 ` Eli Zaretskii
2010-04-29 16:13 ` Phil Muldoon
2010-04-26 21:45 ` Tom Tromey
2010-04-26 21:52 ` Phil Muldoon
2010-04-27 3:09 ` Tom Tromey
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=4BD73A07.7020706@redhat.com \
--to=pmuldoon@redhat.com \
--cc=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