[RFC] Queries and frontends

[RFC] Queries and frontends

[Marc Khouzam]

Hi,

We've been having trouble with PRecord and Frontends, when using
queries.
The problem is that Frontends can't always handle queries properly.
So here is a suggestion.

First, let's mention the "set confirm off" command.  The documentation
at section 20.7 reads:
"If you are willing to unflinchingly face the consequences of your own 
commands, you can disable this "feature":"

So, from the doc and from what seems (to me :-)) like the proper 
behavior, when we "set confirm off", all commands that use a query 
should simply be performed without asking the user.

The current implementation of queries does not do that.  Instead,
it will follow the default answer of a query.  Such a default answer
makes sense when trying to guide the user in a choice, but when
"set confirm off" we should really let the command execute.

As an example, setting pending breakpoints has a default answer of 'n'.
What that means (unless I'm wrong) is that with "set confirm off",
pending breakpoints will NOT be set.

The patch below changes defaulted_query() to always answer "yes" if
'confirm' is off.

I don't think I can make the same change for input that is not from 
a terminal because this whole nquery() yquery() was introduced to
preserve behavior in batch mode, according to
http://sourceware.org/ml/gdb/2004-02/msg00108.html

If this is approved, it would allow frontends to simply ignore all
queries and let commands be executed as requested.  This would allow
to use PRecord without changing any of its queries.

But I'm not entirely sure about this, because of the original 
'batch mode problem' that caused this whole defaulted query thing.
Any thoughts?

Thanks

Marc

2009-07-20  Marc Khouzam  <marc.khouzam@ericsson.com>

	* utils.c (defaulted_query): Always answer "yes" when prompts
	are off.

### Eclipse Workspace Patch 1.0
#P src
Index: gdb/utils.c
===================================================================
RCS file: /cvs/src/src/gdb/utils.c,v
retrieving revision 1.213
diff -u -r1.213 utils.c
--- gdb/utils.c	2 Jul 2009 17:21:07 -0000	1.213
+++ gdb/utils.c	21 Jul 2009 03:12:34 -0000
@@ -1385,7 +1385,9 @@
    Ask user a y-or-n question and return 0 if answer is no, 1 if
    answer is yes, or default the answer to the specified default
    (for yquery or nquery).  DEFCHAR may be 'y' or 'n' to provide a
-   default answer, or '\0' for no default.
+   default answer, or '\0' for no default.  If prompts are disabled
+   we answer 'y' automatically; this allows the command in question
+   to actually be performed.
    CTLSTR is the control string and should end in "? ".  It should
    not say how to answer, because we do that.
    ARGS are the arguments passed along with the CTLSTR argument to
@@ -1427,10 +1429,9 @@
       n_string = "[n]";
     }
 
-  /* Automatically answer the default value if the user did not want
-     prompts.  */
+  /* Automatically answer "yes" if the user did not want prompts.  */
   if (! caution)
-    return def_value;
+    return 1;
 
   /* If input isn't coming from the user directly, just say what
      question we're asking, and then answer "yes" automatically.  This

Re: [RFC] Queries and frontends

[Nick Roberts]

 > First, let's mention the "set confirm off" command.  The documentation
 > at section 20.7 reads:
 > "If you are willing to unflinchingly face the consequences of your own 
 > commands, you can disable this "feature":"
 > 
 > So, from the doc and from what seems (to me :-)) like the proper 
 > behavior, when we "set confirm off", all commands that use a query 
 > should simply be performed without asking the user.
 >
 > The current implementation of queries does not do that.  Instead,
 > it will follow the default answer of a query.  Such a default answer
 > makes sense when trying to guide the user in a choice, but when
 > "set confirm off" we should really let the command execute.

The behaviour is as I would expect from the documentation.

 > As an example, setting pending breakpoints has a default answer of 'n'.
 > What that means (unless I'm wrong) is that with "set confirm off",
 > pending breakpoints will NOT be set.
 > 
 > The patch below changes defaulted_query() to always answer "yes" if
 > 'confirm' is off.

I would find this behaviour confusing.  In any case, the "set confirm off"
command is for interactive use, not front ends.

Here's a revised patch for my original request.  It doesn't help with issues
relating to GDB/MI but just uses the "server prefix" instead of a special
option.  I have used this trick previously (2007-07-10) to avoid setting the
convenience variable $_ with breakpoints.  This seems appropriate as I think
the "server" command was created many years ago by Tom Lord or Jim Kingdon for
use with annotations.  I could add a suitable note to the documentation.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2009-07-21  Nick Roberts  <nickrob@snap.net.nz>

	* record.c (cmd_record_stop): Don't ask for confirmation if
	server prefix is used.


*** record.c.~1.8.~	2009-07-21 17:58:01.000000000 +1200
--- record.c	2009-07-21 18:02:30.000000000 +1200
***************
*** 24,29 ****
--- 24,30 ----
  #include "event-top.h"
  #include "exceptions.h"
  #include "record.h"
+ #include "top.h"
  
  #include <signal.h>
  
*************** cmd_record_stop (char *args, int from_tt
*** 1157,1164 ****
  {
    if (current_target.to_stratum == record_stratum)
      {
!       if (!record_list || !from_tty || query (_("Delete recorded log and "
! 	                                        "stop recording?")))
  	unpush_target (&record_ops);
      }
    else
--- 1158,1165 ----
  {
    if (current_target.to_stratum == record_stratum)
      {
!       if (!record_list || !from_tty || server_command 
! 	  || query (_("Delete recorded log and stop recording?")))
  	unpush_target (&record_ops);
      }
    else

Re: [RFC] Queries and frontends

[Hui Zhu]

On Tue, Jul 21, 2009 at 14:13, Nick Roberts<nickrob@snap.net.nz> wrote:
>  > First, let's mention the "set confirm off" command.  The documentation
>  > at section 20.7 reads:
>  > "If you are willing to unflinchingly face the consequences of your own
>  > commands, you can disable this "feature":"
>  >
>  > So, from the doc and from what seems (to me :-)) like the proper
>  > behavior, when we "set confirm off", all commands that use a query
>  > should simply be performed without asking the user.
>  >
>  > The current implementation of queries does not do that.  Instead,
>  > it will follow the default answer of a query.  Such a default answer
>  > makes sense when trying to guide the user in a choice, but when
>  > "set confirm off" we should really let the command execute.
>
> The behaviour is as I would expect from the documentation.
>
>  > As an example, setting pending breakpoints has a default answer of 'n'.
>  > What that means (unless I'm wrong) is that with "set confirm off",
>  > pending breakpoints will NOT be set.
>  >
>  > The patch below changes defaulted_query() to always answer "yes" if
>  > 'confirm' is off.
>
> I would find this behaviour confusing.  In any case, the "set confirm off"
> command is for interactive use, not front ends.
>
> Here's a revised patch for my original request.  It doesn't help with issues
> relating to GDB/MI but just uses the "server prefix" instead of a special
> option.  I have used this trick previously (2007-07-10) to avoid setting the
> convenience variable $_ with breakpoints.  This seems appropriate as I think
> the "server" command was created many years ago by Tom Lord or Jim Kingdon for
> use with annotations.  I could add a suitable note to the documentation.
>
> --
> Nick                                           http://www.inet.net.nz/~nickrob
>
>
> 2009-07-21  Nick Roberts  <nickrob@snap.net.nz>
>
>        * record.c (cmd_record_stop): Don't ask for confirmation if
>        server prefix is used.
>
>
> *** record.c.~1.8.~     2009-07-21 17:58:01.000000000 +1200
> --- record.c    2009-07-21 18:02:30.000000000 +1200
> ***************
> *** 24,29 ****
> --- 24,30 ----
>  #include "event-top.h"
>  #include "exceptions.h"
>  #include "record.h"
> + #include "top.h"
>
>  #include <signal.h>
>
> *************** cmd_record_stop (char *args, int from_tt
> *** 1157,1164 ****
>  {
>    if (current_target.to_stratum == record_stratum)
>      {
> !       if (!record_list || !from_tty || query (_("Delete recorded log and "
> !                                               "stop recording?")))
>        unpush_target (&record_ops);
>      }
>    else
> --- 1158,1165 ----
>  {
>    if (current_target.to_stratum == record_stratum)
>      {
> !       if (!record_list || !from_tty || server_command
> !         || query (_("Delete recorded log and stop recording?")))
>        unpush_target (&record_ops);
>      }
>    else
>

About this patch.  I had said that I think add a special command for
it is better.

Thanks,
Hui

Re: [RFC] Queries and frontends

[Hui Zhu]

On Tue, Jul 21, 2009 at 16:26, Hui Zhu<teawater@gmail.com> wrote:
> On Tue, Jul 21, 2009 at 14:13, Nick Roberts<nickrob@snap.net.nz> wrote:
>>  > First, let's mention the "set confirm off" command.  The documentation
>>  > at section 20.7 reads:
>>  > "If you are willing to unflinchingly face the consequences of your own
>>  > commands, you can disable this "feature":"
>>  >
>>  > So, from the doc and from what seems (to me :-)) like the proper
>>  > behavior, when we "set confirm off", all commands that use a query
>>  > should simply be performed without asking the user.
>>  >
>>  > The current implementation of queries does not do that.  Instead,
>>  > it will follow the default answer of a query.  Such a default answer
>>  > makes sense when trying to guide the user in a choice, but when
>>  > "set confirm off" we should really let the command execute.
>>
>> The behaviour is as I would expect from the documentation.
>>
>>  > As an example, setting pending breakpoints has a default answer of 'n'.
>>  > What that means (unless I'm wrong) is that with "set confirm off",
>>  > pending breakpoints will NOT be set.
>>  >
>>  > The patch below changes defaulted_query() to always answer "yes" if
>>  > 'confirm' is off.
>>
>> I would find this behaviour confusing.  In any case, the "set confirm off"
>> command is for interactive use, not front ends.
>>
>> Here's a revised patch for my original request.  It doesn't help with issues
>> relating to GDB/MI but just uses the "server prefix" instead of a special
>> option.  I have used this trick previously (2007-07-10) to avoid setting the
>> convenience variable $_ with breakpoints.  This seems appropriate as I think
>> the "server" command was created many years ago by Tom Lord or Jim Kingdon for
>> use with annotations.  I could add a suitable note to the documentation.
>>
>> --
>> Nick                                           http://www.inet.net.nz/~nickrob
>>
>>
>> 2009-07-21  Nick Roberts  <nickrob@snap.net.nz>
>>
>>        * record.c (cmd_record_stop): Don't ask for confirmation if
>>        server prefix is used.
>>
>>
>> *** record.c.~1.8.~     2009-07-21 17:58:01.000000000 +1200
>> --- record.c    2009-07-21 18:02:30.000000000 +1200
>> ***************
>> *** 24,29 ****
>> --- 24,30 ----
>>  #include "event-top.h"
>>  #include "exceptions.h"
>>  #include "record.h"
>> + #include "top.h"
>>
>>  #include <signal.h>
>>
>> *************** cmd_record_stop (char *args, int from_tt
>> *** 1157,1164 ****
>>  {
>>    if (current_target.to_stratum == record_stratum)
>>      {
>> !       if (!record_list || !from_tty || query (_("Delete recorded log and "
>> !                                               "stop recording?")))
>>        unpush_target (&record_ops);
>>      }
>>    else
>> --- 1158,1165 ----
>>  {
>>    if (current_target.to_stratum == record_stratum)
>>      {
>> !       if (!record_list || !from_tty || server_command
>> !         || query (_("Delete recorded log and stop recording?")))
>>        unpush_target (&record_ops);
>>      }
>>    else
>>
>
> About this patch.  I had said that I think add a special command for
> it is better.
>
BTW,  what about this?

maintenance print target-stack
The current target stack is:
  - record (Process record and replay target)
  - child (Unix child process)
  - exec (Local exec file)
  - None (None)

Thanks,
Hui

Re: [RFC] Queries and frontends

[Nick Roberts]

 > > About this patch.  I had said that I think add a special command for
 > > it is better.

It was a different patch which didn't add a new option but used an existing
feature, namely the server prefix.

 > BTW,  what about this?
 > 
 > maintenance print target-stack
 > The current target stack is:
 >   - record (Process record and replay target)
 >   - child (Unix child process)
 >   - exec (Local exec file)
 >   - None (None)

I don't understand how this command relates to queries.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Queries and frontends

[Michael Snyder]

Nick Roberts wrote:

> Here's a revised patch for my original request.  It doesn't help with issues
> relating to GDB/MI but just uses the "server prefix" instead of a special
> option.  I have used this trick previously (2007-07-10) to avoid setting the
> convenience variable $_ with breakpoints.  This seems appropriate as I think
> the "server" command was created many years ago by Tom Lord or Jim Kingdon for
> use with annotations.  I could add a suitable note to the documentation.

Kingdon, 1994: Not terribly well documented.


Mon Apr 11 10:44:35 1994  Jim Kingdon  (kingdon@deneb.cygnus.com)

         * main.c (main): Accept --annotate=N option and make --fullname
         the same as --annotate=1.
         (command_line_input): Print annotatation before and after prompt.
         * blockframe.c (flush_cached_frames): Print annotation.
         * Rename frame_file_full_name to annotation_level and move it from
         symtab.h to defs.h.
         * source.c (identify_source_line): If annotation_level > 1,
         change output format.
         * breakpoint.c: Print annotation whenever a breakpoint changes.
         * main.c: New variable server_command.
         (command_line_input): Parse "server " and set server_command.
         (dont_repeat): Check server_command.

RE: [RFC] Queries and frontends

[Marc Khouzam]

> -----Original Message-----
> From: Nick Roberts [mailto:nickrob@snap.net.nz] 
> Sent: July-21-09 2:14 AM
> To: Marc Khouzam
> Cc: gdb@sourceware.org
> Subject: Re: [RFC] Queries and frontends
> 
> 
>  > First, let's mention the "set confirm off" command.  The 
> documentation
>  > at section 20.7 reads:
>  > "If you are willing to unflinchingly face the consequences 
> of your own 
>  > commands, you can disable this "feature":"
>  > 
>  > So, from the doc and from what seems (to me :-)) like the proper 
>  > behavior, when we "set confirm off", all commands that use a query 
>  > should simply be performed without asking the user.
>  >
>  > The current implementation of queries does not do that.  Instead,
>  > it will follow the default answer of a query.  Such a 
> default answer
>  > makes sense when trying to guide the user in a choice, but when
>  > "set confirm off" we should really let the command execute.
> 
> The behaviour is as I would expect from the documentation.

I guess it's just me then.
But with "set confirm off", which one may choose to use, how
would you set pending breakpoints, currently?
You just won't be able to, right?  Isn't that a problem?

In fact, any code using nquery() will not be able to be used
by anyone using "set confirm off".  Which is the problem with
PRecord for me.  I'm thinking this is a more general problem
than just fixing PRecord.


>  > As an example, setting pending breakpoints has a default 
> answer of 'n'.
>  > What that means (unless I'm wrong) is that with "set confirm off",
>  > pending breakpoints will NOT be set.
>  > 
>  > The patch below changes defaulted_query() to always answer "yes" if
>  > 'confirm' is off.
> 
> I would find this behaviour confusing.  In any case, the "set 
> confirm off"
> command is for interactive use, not front ends.
> 
> Here's a revised patch for my original request.  It doesn't 
> help with issues
> relating to GDB/MI but just uses the "server prefix" instead 
> of a special
> option.  I have used this trick previously (2007-07-10) to 
> avoid setting the
> convenience variable $_ with breakpoints.  This seems 
> appropriate as I think
> the "server" command was created many years ago by Tom Lord 
> or Jim Kingdon for
> use with annotations.  I could add a suitable note to the 
> documentation.
> 
> -- 
> Nick                                           
> http://www.inet.net.nz/~nickrob
> 
> 
> 2009-07-21  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* record.c (cmd_record_stop): Don't ask for confirmation if
> 	server prefix is used.
> 
> 
> *** record.c.~1.8.~	2009-07-21 17:58:01.000000000 +1200
> --- record.c	2009-07-21 18:02:30.000000000 +1200
> ***************
> *** 24,29 ****
> --- 24,30 ----
>   #include "event-top.h"
>   #include "exceptions.h"
>   #include "record.h"
> + #include "top.h"
>   
>   #include <signal.h>
>   
> *************** cmd_record_stop (char *args, int from_tt
> *** 1157,1164 ****
>   {
>     if (current_target.to_stratum == record_stratum)
>       {
> !       if (!record_list || !from_tty || query (_("Delete 
> recorded log and "
> ! 	                                        "stop recording?")))
>   	unpush_target (&record_ops);
>       }
>     else
> --- 1158,1165 ----
>   {
>     if (current_target.to_stratum == record_stratum)
>       {
> !       if (!record_list || !from_tty || server_command 
> ! 	  || query (_("Delete recorded log and stop recording?")))
>   	unpush_target (&record_ops);
>       }
>     else
> 

Re: [RFC] Queries and frontends

[Daniel Jacobowitz]

On Tue, Jul 21, 2009 at 02:36:38PM -0400, Marc Khouzam wrote:
> I guess it's just me then.
> But with "set confirm off", which one may choose to use, how
> would you set pending breakpoints, currently?
> You just won't be able to, right?  Isn't that a problem?

In fact:

(gdb) show breakpoint pending
Debugger's behavior regarding pending breakpoints is auto.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [RFC] Queries and frontends

[Nick Roberts]

Daniel Jacobowitz writes:
 > On Tue, Jul 21, 2009 at 02:36:38PM -0400, Marc Khouzam wrote:
 > > I guess it's just me then.
 > > But with "set confirm off", which one may choose to use, how
 > > would you set pending breakpoints, currently?
 > > You just won't be able to, right?  Isn't that a problem?
 > 
 > In fact:
 > 
 > (gdb) show breakpoint pending
 > Debugger's behavior regarding pending breakpoints is auto.

GDB never prompts with pending breakpoints in GDB/MI because it temporarly
sets deprecated_query_hook:

  deprecated_query_hook = mi_interp_query_hook
   
In any case I'm not concerned about all queries: if they're issued from the
GUD buffer Emacs currently handles them fine.  I just need to avoid them for
those GDB commands which are run behind the users back.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Queries and frontends

[Hui Zhu]

On Tue, Jul 21, 2009 at 19:51, Nick Roberts<nickrob@snap.net.nz> wrote:
>  > > About this patch.  I had said that I think add a special command for
>  > > it is better.
>
> It was a different patch which didn't add a new option but used an existing
> feature, namely the server prefix.
>
>  > BTW,  what about this?
>  >
>  > maintenance print target-stack
>  > The current target stack is:
>  >   - record (Process record and replay target)
>  >   - child (Unix child process)
>  >   - exec (Local exec file)
>  >   - None (None)
>
> I don't understand how this command relates to queries.

This command can tell you current use prec or not.

RE: [RFC] Queries and frontends

[Marc Khouzam]

> -----Original Message-----
> From: Daniel Jacobowitz [mailto:drow@false.org] 
> Sent: Tuesday, July 21, 2009 2:55 PM
> To: Marc Khouzam
> Cc: Nick Roberts; gdb@sourceware.org
> Subject: Re: [RFC] Queries and frontends
> 
> On Tue, Jul 21, 2009 at 02:36:38PM -0400, Marc Khouzam wrote:
> > I guess it's just me then.
> > But with "set confirm off", which one may choose to use, how
> > would you set pending breakpoints, currently?
> > You just won't be able to, right?  Isn't that a problem?
> 
> In fact:
> 
> (gdb) show breakpoint pending
> Debugger's behavior regarding pending breakpoints is auto.

Ah. :-)
Ok, then, if that is the prefered approach.  Seems like it will
be a pain to add special options for each new nquery() use.
But if no one else feels it's a problem, that's fine with me.

Thanks

Marc

Re: [RFC] Queries and frontends

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> Here's a revised patch for my original request.  It doesn't help
Nick> with issues relating to GDB/MI but just uses the "server prefix"
Nick> instead of a special option.

My initial reaction to this was to think that defaulted_query should
respect server_command.  Is there a case where this would do the wrong
thing?

Tom

Re: [RFC] Queries and frontends

[Nick Roberts]

 > Nick> Here's a revised patch for my original request.  It doesn't help
 > Nick> with issues relating to GDB/MI but just uses the "server prefix"
 > Nick> instead of a special option.
 > 
 > My initial reaction to this was to think that defaulted_query should
 > respect server_command.  Is there a case where this would do the wrong
 > thing?

I don't quite follow.  AFAIK defaulted_query knows nothing about
server_command.  I guess it would be possible to make GDB never query when
the server prefix is used but the long term goal is to remove annotations.
I'm just proposing that "record stop" doesn't need confirmation when the
server prefix is used.  Since "record stop" is new to GDB 7.0 that won't
break/change existing behaviour so I don't see how it can do the wrong
thing if it's properly implemented.

Hui has suggested adding a special command but I don't understand how his
proposed "maintenance print target-stack" relates to queries.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Queries and frontends

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> I don't quite follow.  AFAIK defaulted_query knows nothing about
Nick> server_command.

Yes, but it could.

Since "server" is intended to hide commands from the user, why check
server_command at one particular query rather than in every query?

Nick> Hui has suggested adding a special command but I don't understand how his
Nick> proposed "maintenance print target-stack" relates to queries.

Me neither.

Tom

Re: [RFC] Queries and frontends

[Nick Roberts]

Tom Tromey writes:
 > >>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:
 > 
 > Nick> I don't quite follow.  AFAIK defaulted_query knows nothing about
 > Nick> server_command.
 > 
 > Yes, but it could.
 > 
 > Since "server" is intended to hide commands from the user, why check
 > server_command at one particular query rather than in every query?

Because that would change existing behaviour.  It's probably a small risk as
no one else appears to be using the server prefix or, if they are, they have
kept a very low profile.  Just changing "record stop" is sufficient for Emacs
at the moment.  You could say it's quick and nasty but I would call it
pragmatic.

We could still change it in the future but I thought annotations were
deprecated i.e. on the path to being removed and their development generally
discouraged (I see the server prefix as part of annotations.

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: [RFC] Queries and frontends

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Tom> Since "server" is intended to hide commands from the user, why check
Tom> server_command at one particular query rather than in every query?

Nick> Because that would change existing behaviour.  It's probably a
Nick> small risk as no one else appears to be using the server prefix
Nick> or, if they are, they have kept a very low profile.  Just changing
Nick> "record stop" is sufficient for Emacs at the moment.  You could
Nick> say it's quick and nasty but I would call it pragmatic.

It seems to me that this is just a bug in the server prefix.  The intent
is to hide some actions from the user.  But, a query is definitely not
hidden.

My concern with the one-off is that it is unclear why the check is where
it is.  And the answer, when someone in the future looks it up, will be
"Emacs needed that".

I tend to think that the more generic change would be safe, and cleaner.

Tom

[PATCH] util.c + doc [was Re: [RFC] Queries and frontends]

[Nick Roberts]

 > I tend to think that the more generic change would be safe, and cleaner.

This should do it.

-- 
Nick                                           http://www.inet.net.nz/~nickrob


2009-07-30  Nick Roberts  <nickrob@snap.net.nz>

	* utils.c (defaulted_query): Don't ask for confirmation if server
	prefix is used.


2009-07-30  Nick Roberts  <nickrob@snap.net.nz>

	* gdb.texinfo (Server Prefix): Explain that server prefix suppresses
	confirmation request.


*** utils.c.~1.215.~	2009-07-22 15:29:54.000000000 +1200
--- utils.c	2009-07-30 11:39:08.000000000 +1200
*************** defaulted_query (const char *ctlstr, con
*** 1436,1443 ****
      }
  
    /* Automatically answer the default value if the user did not want
!      prompts.  */
!   if (! caution)
      return def_value;
  
    /* If input isn't coming from the user directly, just say what
--- 1436,1443 ----
      }
  
    /* Automatically answer the default value if the user did not want
!      prompts or the command was issued with the server prefix.  */
!   if (! caution || server_command)
      return def_value;
  
    /* If input isn't coming from the user directly, just say what



*** gdb.texinfo.~1.609.~	2009-07-29 18:47:32.000000000 +1200
--- gdb.texinfo	2009-07-30 11:49:16.000000000 +1200
*************** The server prefix does not affect the re
*** 25607,25612 ****
--- 25607,25616 ----
  history; to print a value without recording it into the value history,
  use the @code{output} command instead of the @code{print} command.
  
+ It also disables confirmation requests irrespective of the value of
+ the @code{show confirm} command (@pxref{Messages/Warnings, ,Optional
+ Warnings and Messages}).
+ 
  @node Prompting
  @section Annotation for @value{GDBN} Input
  

RE: [PATCH] util.c + doc [was Re: [RFC] Queries and frontends]

[Marc Khouzam]

 

> -----Original Message-----
> From: gdb-owner@sourceware.org 
> [mailto:gdb-owner@sourceware.org] On Behalf Of Nick Roberts
> Sent: July-29-09 7:56 PM
> To: Tom Tromey
> Cc: Marc Khouzam; gdb@sourceware.org; gdb-patches@sourceware.org
> Subject: [PATCH] util.c + doc [was Re: [RFC] Queries and frontends]
> 
> 
>  > I tend to think that the more generic change would be 
> safe, and cleaner.
> 
> This should do it.
> -- 
> Nick                                           
> http://www.inet.net.nz/~nickrob
> 
> 
> 2009-07-30  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* utils.c (defaulted_query): Don't ask for confirmation 
> if server
> 	prefix is used.
> 
> 
> 2009-07-30  Nick Roberts  <nickrob@snap.net.nz>
> 
> 	* gdb.texinfo (Server Prefix): Explain that server 
> prefix suppresses
> 	confirmation request.
> 
> 
> *** utils.c.~1.215.~	2009-07-22 15:29:54.000000000 +1200
> --- utils.c	2009-07-30 11:39:08.000000000 +1200
> *************** defaulted_query (const char *ctlstr, con
> *** 1436,1443 ****
>       }
>   
>     /* Automatically answer the default value if the user did not want
> !      prompts.  */
> !   if (! caution)
>       return def_value;
>   
>     /* If input isn't coming from the user directly, just say what
> --- 1436,1443 ----
>       }
>   
>     /* Automatically answer the default value if the user did not want
> !      prompts or the command was issued with the server prefix.  */
> !   if (! caution || server_command)
>       return def_value;
>   


Doesn't this amount to using "set confirm off"?
I might have missed it, but I don't remember why you didn't want
use that instead?

And this solution does not help (some) frontends with 
answering 'y' to nquery()
 
How about:

   if (! caution)
       return def_value;

   if (server_command)
       return 1;


>     /* If input isn't coming from the user directly, just say what
> 
> 
> 
> *** gdb.texinfo.~1.609.~	2009-07-29 18:47:32.000000000 +1200
> --- gdb.texinfo	2009-07-30 11:49:16.000000000 +1200
> *************** The server prefix does not affect the re
> *** 25607,25612 ****
> --- 25607,25616 ----
>   history; to print a value without recording it into the 
> value history,
>   use the @code{output} command instead of the @code{print} command.
>   
> + It also disables confirmation requests irrespective of the value of
> + the @code{show confirm} command (@pxref{Messages/Warnings, ,Optional
> + Warnings and Messages}).
> + 
>   @node Prompting
>   @section Annotation for @value{GDBN} Input
>   
> 

Re: [PATCH] util.c + doc [was Re: [RFC] Queries and frontends]

[Eli Zaretskii]

> Date: Thu, 30 Jul 2009 11:55:49 +1200
> Cc: "Marc Khouzam" <marc.khouzam@ericsson.com>, <gdb@sourceware.org>, 	gdb-patches@sourceware.org
> From: nickrob@snap.net.nz (Nick Roberts)
> 
> + It also disables confirmation requests irrespective of the value of
> + the @code{show confirm} command (@pxref{Messages/Warnings, ,Optional
> + Warnings and Messages}).

"value of `show confirm' command" sounds awkward (a command cannot
have a value).  Can you suggest a better wording?

Thanks.

Re: [PATCH] util.c + doc

[Tom Tromey]

>>>>> "Nick" == Nick Roberts <nickrob@snap.net.nz> writes:

Nick> This should do it.

Nick> 2009-07-30  Nick Roberts  <nickrob@snap.net.nz>
Nick> 	* utils.c (defaulted_query): Don't ask for confirmation if server
Nick> 	prefix is used.

This part is ok.
Thanks.

Tom