From: Andrew Cagney <ac131313@cygnus.com>
To: tromey@redhat.com
Cc: Gdb List <gdb@sources.redhat.com>
Subject: Re: Questions about gdb and gettext
Date: Mon, 24 Jun 2002 09:10:00 -0000 [thread overview]
Message-ID: <3D174481.3040108@cygnus.com> (raw)
In-Reply-To: <874rftnu4x.fsf@fleche.redhat.com>
> "Andrew" == Andrew Cagney <ac131313@cygnus.com> writes:
>
>
>>> The idea here is to factor out the first sentence into separate
>>> `show' and `set' sentences, and then keep the rest of the help text
>>> the same.
>
>
> Andrew> Look at add_setshow_boolean_cmd(). The general direction is
> Andrew> for the generic commands to go away being replaced by more
> Andrew> specific, stronger typed, and i18n frendly commands.
Sorry, I completly bleeped over the paragraph where you mentioned you
had examined the setshow functions :-(
> I looked at this. In this case it looks like `help show foo' will
> show a short doc string, while `help set foo' will show more text. Is
> this ok for all set/show commands? If so, then I agree that emulating
> this interface is fine.
Hmm, that is a human factors question, see below.
Anyway, for reference, I'll run through how each of the arguments came
to be:
setshow looks like:
extern void add_setshow_boolean_cmd
(char *name,
enum command_class class,
int *var,
char *set_doc,
char *show_doc,
cmd_sfunc_ftype *set_func,
cmd_sfunc_ftype *show_func,
struct cmd_list_element **set_list,
struct cmd_list_element **show_list);
VS
add_set_and_show
(char *name,
enum command_class class,
Yep.
var_types var_type,
void *var,
setshow has an explictily typed parameter:
int *var;
or
char **var;
so that -Werror, rather than good luck, can be relied on to ensure
parameter types match.
char *first_setline,
char *first_showline,
char *rest_of_docs,
I considered something like this but shyed away from it. I don't know
enough about international languages to trust that it is legitimate [I
suspect it is]. I also noticed that while it makes sense for the set
message to refer to arguments, I don't know if that is valid for a show
message.
Hmm, the problem also can be that the standard of the set/show online
doco has been slipping. The message after the first line just needs to
be better worded so that it is does apply to both the SET and SHOW cases.
What about having the three:
set_doc
show_doc
sup_doc
(i.e. don't restrict it to the first line?).
struct cmd_list_element **list)
A show list ends up being needed (well either that or some sort of
magical gymnastics to guess where the corresponding show command should go).
I also needed to add an explicit set_func and show_func. Otherwize the
interface needs to return both the SET and SHOW versions of the command.
enjoy,
Andrew
next prev parent reply other threads:[~2002-06-24 16:10 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-06-23 13:33 Tom Tromey
2002-06-23 14:33 ` Andrew Cagney
2002-06-23 21:52 ` Tom Tromey
2002-06-24 9:10 ` Andrew Cagney [this message]
2002-06-24 15:12 ` Tom Tromey
2002-06-24 3:32 ` Eli Zaretskii
2002-06-24 5:18 ` Richard Earnshaw
2002-06-24 11:17 ` 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=3D174481.3040108@cygnus.com \
--to=ac131313@cygnus.com \
--cc=gdb@sources.redhat.com \
--cc=tromey@redhat.com \
/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