From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12514 invoked by alias); 24 Jun 2002 16:10:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 12505 invoked from network); 24 Jun 2002 16:10:41 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 24 Jun 2002 16:10:41 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 533213D25; Mon, 24 Jun 2002 12:10:41 -0400 (EDT) Message-ID: <3D174481.3040108@cygnus.com> Date: Mon, 24 Jun 2002 09:10:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020613 X-Accept-Language: en-us, en MIME-Version: 1.0 To: tromey@redhat.com Cc: Gdb List Subject: Re: Questions about gdb and gettext References: <87bsa1pvtv.fsf@fleche.redhat.com> <3D163E9A.1000106@cygnus.com> <874rftnu4x.fsf@fleche.redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-06/txt/msg00217.txt.bz2 > "Andrew" == Andrew Cagney 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