[PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode

[PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode

[Stephane Carrez]

Hi!

When gdb is in TUI SingleKey mode, if a command calls 'prompt_for_continue',
the readline keymap is using the SingleKey tui keymap and this prevents the user
from typing any useful key (such as Return).  Furthermore, typing some SingleKey
command (r, s, n, etc) will execute the command (results are strange).
You can reproduce easily by typing 'info' in SingleKey mode.

In this mode, if you type 'v' (info local), the gdb's prompt is not
displayed at all.

I've committed this patch to fix those issues.

Basically when we execute a gdb command, we must be in TUI_ONE_COMMAND_MODE
(or TUI_COMMAND_MODE).  We must restore the TUI_SINGLE_KEY_MODE only
if we are not called from prompt_for_continue (I've used the check on
'immediate_quit'
for that).

Stephane

Index: ChangeLog
===================================================================
RCS file: /cvs/src/src/gdb/ChangeLog,v
retrieving revision 1.14811
diff -u -p -r1.14811 ChangeLog
--- ChangeLog   10 Nov 2012 12:25:02 -0000      1.14811
+++ ChangeLog   10 Nov 2012 13:11:24 -0000
@@ -1,5 +1,13 @@
 2012-11-10  Stephane Carrez  <Stephane.Carrez@gmail.com>

+       * tui/tui.c (tui_rl_command_key): Switch to TUI_ONE_COMMAND_MODE
+       while executing the gdb command.
+       (tui_rl_startup_hook): Do not switch back to TUI_SINGLE_KEY_MODE if we
+       are called from prompt_for_continue.
+       * tui/tui-io.c (tui_redisplay_readline): Likewise.
+
+2012-11-10  Stephane Carrez  <Stephane.Carrez@gmail.com>
+
        PR tui/9584

        * tui/tui.c (tui_rl_command_key): Do not call execute_command
cvs diff: Diffing tui
Index: tui/tui-io.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui-io.c,v
retrieving revision 1.32
diff -u -p -r1.32 tui-io.c
--- tui/tui-io.c        4 Jan 2012 08:27:58 -0000       1.32
+++ tui/tui-io.c        10 Nov 2012 13:11:24 -0000
@@ -211,8 +211,11 @@ tui_redisplay_readline (void)

   /* Detect when we temporarily left SingleKey and now the readline
      edit buffer is empty, automatically restore the SingleKey
-     mode.  */
-  if (tui_current_key_mode == TUI_ONE_COMMAND_MODE && rl_end == 0)
+     mode.  The restore must only be done if the command has finished.
+     The command could call prompt_for_continue and we must not
+     restore SingleKey so that the prompt and normal keymap are used.  */
+  if (tui_current_key_mode == TUI_ONE_COMMAND_MODE && rl_end == 0
+      && immediate_quit == 0)
     tui_set_key_mode (TUI_SINGLE_KEY_MODE);

   if (tui_current_key_mode == TUI_SINGLE_KEY_MODE)
Index: tui/tui.c
===================================================================
RCS file: /cvs/src/src/gdb/tui/tui.c,v
retrieving revision 1.71
diff -u -p -r1.71 tui.c
--- tui/tui.c   10 Nov 2012 12:25:07 -0000      1.71
+++ tui/tui.c   10 Nov 2012 13:11:24 -0000
@@ -247,6 +247,10 @@ tui_rl_command_key (int count, int key)
              in the readline history which turns out to be better.  */
           rl_insert_text (tui_commands[i].cmd);
           rl_newline (1, '\n');
+
+          /* Switch to gdb command mode while executing the command.
+             This way the gdb's continue prompty will be displayed.  */
+          tui_set_key_mode (TUI_ONE_COMMAND_MODE);
           return 0;
         }
     }
@@ -285,7 +289,7 @@ static int
 tui_rl_startup_hook (void)
 {
   rl_already_prompted = 1;
-  if (tui_current_key_mode != TUI_COMMAND_MODE)
+  if (tui_current_key_mode != TUI_COMMAND_MODE && immediate_quit == 0)
     tui_set_key_mode (TUI_SINGLE_KEY_MODE);
   tui_redisplay_readline ();
   return 0;

Re: [PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode

[Tom Tromey]

>>>>> "Stephane" == Stephane Carrez <stephane.carrez@gmail.com> writes:

Stephane> Basically when we execute a gdb command, we must be in
Stephane> TUI_ONE_COMMAND_MODE (or TUI_COMMAND_MODE).  We must restore
Stephane> the TUI_SINGLE_KEY_MODE only if we are not called from
Stephane> prompt_for_continue (I've used the check on 'immediate_quit'
Stephane> for that).

I don't know this code at all, but I think checking immediate_quit here
is weird.  Partly this is because I think most uses of immediate_quit in
gdb are incorrect, and I'd like to try to phase them out -- but having
the TUI depend on it makes this harder.  Is there some other way to do
it?

Tom

Re: [PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode

[Stephane Carrez]

Tom,

On Mon, Nov 12, 2012 at 4:44 PM, Tom Tromey <tromey@redhat.com> wrote:
>
> I don't know this code at all, but I think checking immediate_quit here
> is weird.  Partly this is because I think most uses of immediate_quit in
> gdb are incorrect, and I'd like to try to phase them out -- but having
> the TUI depend on it makes this harder.  Is there some other way to do
> it?
>
> Tom

I agree this is weird but I have not found any better solution without
changing the core gdb.

The problem is that the TUI must know that a gdb command is being executed.
This way, if it interacts with the user, it has to be in the mode
where a prompt is displayed.

If we add some boolean predicate function that tells us we are executing some
command (whatever the command, a user, a set, a show, ...) this would
be fine for me.
Some kind of 'is_executing_command_p'.

Another way is to get an observer that allows the TUI to know when a command
is finished. This way, it could do switch the TUI back to the
SingleKey once the command
is done.  Adding an observer for this looks a little bit overkill.

If anybody has a better solution, I would appreciate it too!

Stephane

Re: [PATCH]: Fix gdb's prompt for continue in TUI SingleKey mode

[Tom Tromey]

>>>>> "Stephane" == Stephane Carrez <stephane.carrez@gmail.com> writes:

Stephane> The problem is that the TUI must know that a gdb command is
Stephane> being executed.  This way, if it interacts with the user, it
Stephane> has to be in the mode where a prompt is displayed.

Stephane> If we add some boolean predicate function that tells us we are
Stephane> executing some command (whatever the command, a user, a set, a
Stephane> show, ...) this would be fine for me.  Some kind of
Stephane> 'is_executing_command_p'.

Something like this would be fine by me.

Tom