> I am unaware of any gdb command that will enter/exit TUI mode independently of
the key combination.  Is there one?

Commands like "tui foo", and "layout next" enter the TUI.

I'm not aware of any GDB command to exit the TUI, and looking at the code, I can't find any that would do it as side effect.

However, TUI enter/exit is bound to the readline "tui-switch-mode" command/function:

>  rl_add_defun ("tui-switch-mode", tui_rl_switch_mode, -1);

One should be able to use that to bind any key combo to TUI enter/exit in the inputrc file, per the "Key Bindings" node in the readline manual.  However, I'm not familiar readline's vi mode (emacs user here), and whether key bindings apply in that mode.

Let me know if that helps.

> However, TUI enter/exit is bound to the readline "tui-switch-mode"
> command/function...
> One should be able to use that to bind any key combo to TUI enter/exit in the
> inputrc file, per the "Key Bindings" node in the readline manual.  However, I'm
> not familiar readline's vi mode (emacs user here), and whether key bindings
> apply in that mode.

I'm not familiar either.  Thanks for the suggestion.  I've tried
adding a few things like

Control-x: tui-switch-mode

to my ~/.inputrc without any luck.  However, it seems that

1. Run 'gdb'
2. Hit Escape to enter vi command mode
3. Hit Control-E to enter Emacs mode ('emacs-editing-mode')
4. Hit Control-x a to enter the TUI

works.  Though now I'm in Emacs mode and hitting Control-x a again
does not exit the TUI.  And I can't seem to get  "M-C-J" to trigger
vi-editing-mode again (though this is likely me being an idiot).

- Rhys

I'm afraid at this point I don't really know if there's a bug, or if there is, if it is GDB specific.  As mentioned, I'm blissfully ignorant on vi things.
However, I'd think that if bash can handle the same style of key bindings in vi mode, then gdb should too.  What does bash do?

> (though this is likely me being an idiot).

:-)  Most probably not.

A gdb command to toggle the TUI off seems like something nice to have, as escape hatch out of broken-beyond-repair terminal settings though.

This is the workaround I found:

in my ~/.inputrc , I added a line that looks like this:
C-P: tui-switch-mode

i.e. ctrl-p will do the switch.

Then, in gdb's source, in the file gdb/tui/tui.c , I found the call that normally looks like this:

rl_add_defun ("tui-switch-mode", tui_rl_switch_mode, -1);

and changed the 3rd parameter (i.e. the key) to be a 16. Why 16? it's what the macro CTRL(X) will do for the letter I want to assign (i.e. ctrl-p in my case).

After that, I can exit in vi-keys out of tui mode by pressing ctrl-p.


So what is the real fix?
It seems to me that a solution will have to do with changing the function "tui_initialize_readline", which is the one that is being called at startup in a way that it hardcodes a key of with value -1 to the "tui-switch-mode", so that the user can provide their own key for it. My question is why is there a -1 being assigned to that function right now in the first place. Does anybody know ?

I changed my workaround by to not hard-code a key combination for exiting the tui mode, and instead pick up a key combination from the ~/.inputrc file, , by modifying the function tui_initialize_readline to call rl_re_read_init_file (in readline/bind.c) before returning.

My ~/.inputrc now has a keyboard mapping to associate to "tui-switch-mode". Regardless, for a better out-of-the-box experience perhaps a better default for vi key bindings is needed, at least for "tui-switch-mode", then things would work without requiring users to modify ~/.inputrc or similar.

Notice that even when using `gdb -tui` to start gdb in TUI mode, it's impossible to switch to the single key mode as `^X,s` doesn't work with vi bindings neither. Using `<Esc>,^E` does help but as the bindings reset to vi mode when you exit the single key mode, you need to redo it every time which makes the single key mode just not worth it -- even having a command like "tui single-key" would be faster than doing this, but unfortunately gdb doesn't seem to provide anything like this.

Is there any workaround that would allow to use keys starting with `^X` in vi mode?

Not being able to bind ^X,s in vi-mode is perhaps related to ^X alone being bound to self-insert. In any case, I think you're asking the wrong question. Key sequences starting with Ctrl-X is really an emacs thing. What you should be asking is what a natural key combination in vi-mode would be.

I would instead suggest binding a sequence starting with a backslash in vi command mode. This is perhaps more of a vim convention. If you want to look at the vim documentation, see :help leader. <Leader> is a special token in vim key bindings and is a common prefix for keys used by plugins and user configuration. Some people redefine leader to, e.g. comma but comma does have a use even in original vi.

Can someone try this out with git master gdb?

I think the "SingleKey" keymap change should have made it so that
tui-switch-mode can now be bound in ~/.inputrc.

Also, now there is a "tui disable" command to get out of the TUI
without using the special key binding.

So, I think this bug is probably fixed.

I recently dealt with this a bit, so here are my notes:

Short version: It *mostly* works. With a few workarounds, I have a decent experience with vi-mode in GDB+TUI.

Details:

    $ gdb --version
    GNU gdb (Debian 8.2.1-2+b3) 8.2.1

As far as I could tell, GDB does not have default mappings for the tui-xxx readline bindings.
Certainly, using C-x,C-a or similar did nothing (just printed "^X^A" for me), but I'm unaware of any other mapping established.

This is my first gripe: there seems to be no way to dump out the mappings, to know what I'm working with

Regardless, I created a file ".inputrc.gdb" with these contents:

    set editing-mode vi
    # GDB only maps this stuff in emacs mode.
    # So, we just do the same for vi-mode.
    set keymap vi-insert
    "\C-x\C-a": tui-switch-mode
    "\C-xa": tui-switch-mode
    "\C-xA": tui-switch-mode
    "\C-x1": tui-delete-other-windows
    "\C-x2": tui-change-windows
    "\C-xo": tui-other-window
    "\C-xs": next-keymap
    set keymap vi-command
    "\C-x\C-a": tui-switch-mode
    "\C-xa": tui-switch-mode
    "\C-xA": tui-switch-mode
    "\C-x1": tui-delete-other-windows
    "\C-x2": tui-change-windows
    "\C-xo": tui-other-window
    "\C-xs": next-keymap

Then, I run gdb with:

    $ INPUTRC=.inputrc.gdb gdb path/to/my/program

However, this did not immediately work!
I still got literal "^X^A" when I tried to use it.

I got to wondering if somehow GDB was *stripping* my mappings on startup, when it configures its own readline internally.
I haven't confirmed this, but it seems plausible given the next thing I tried:

(1) I added this line to my .inputrc.gdb:

    "\C-x\C-r": re-read-init-file

[That line appears twice - once under 'vi-insert' keymap, and once under 'vi-command']

(2) After gdb starts up (same commandline as used above), I first do C-x,C-r to reload my config.
Then, after that, my C-x,C-a bindings work! I can switch to TUI, while still staying in vi mode.

Single key mode works too.

Some other comments:

* You must type C-x,<whatever> quickly. The default timeout is 500ms. You can change that in readline with keyseq-timeout.

* The need to re-load the config after startup is strange and confusing. Seems like a bug to me.

* Comment #7 has a point that the C-X mappings are not very idiomatic for vi. At present, there simply are zero mappings, so I guess that sidestepps the issue. But that fact is not obvious from the GDB docs; they don't discuss edit mode differences. [aside, re: last sentence of Comment #7: comma *does* have a meaning in original vi - do ';' but in reverse)

Still seems to require some workaround, reopening for investigation.

(In reply to Rhys Ulerich from comment #0)
> Having vi-like settings in ~/.inputrc
> breaks entering/exiting TUI mode using C-x a or any other key combination
> documented at
> http://sourceware.org/gdb/download/onlinedocs/gdb/TUI-Keys.html.
> 
> To reproduce:
> 
> 1. Remove any ~/.inputrc file.
> 2. Run 'gdb'
> 3. Hit C-x a and observe TUI mode starting.
> 4. Quit gdb
> 5. Create a ~/.inputrc file containing two lines:
>    > set editing-mode vi
>    > set keymap vi
> 6. Run 'gdb'
> 7. Hit C-x a and observe ^X^A being echoed to the screen but TUI mode not
> starting.
> 

Reproduced on current trunk.

There are three toplevel keymaps in readline:
- emacs_standard_keymap -> emacs_meta_keymap
                        -> emacs_ctlx_keymap
- vi_insertion_keymap
- vi_movement_keymap

For rl_editing_mode == emacs_mode, we get emacs_standard_keymap and for rl_editing_mode == vi_mode we get vi_insertion_keymap or vi_movement_keymap.

In gdb/tui/tui.c, we add another toplevel keymap for SingleKey mode, confusingly called tui_keymap.

Like the emacs toplevel keymap, it gets assigned a ctlx submap: tui_ctlx_keymap.

Then we do:
...
  rl_bind_key_in_map (CTRL ('A'), tui_rl_switch_mode, emacs_ctlx_keymap);
  rl_bind_key_in_map (CTRL ('A'), tui_rl_switch_mode, tui_ctlx_keymap);
...
making sure that C-x C-a works for toplevel keymaps emacs_standard_keymap and tui_keymap.

Nothing is done for the toplevel vi keymaps, so those keys don't work there.

Fixed by:
...
   rl_generic_bind (ISKMAP, "\\C-x", (char*) tui_ctlx_keymap, tui_keymap);
+  rl_generic_bind (ISKMAP, "\\C-x", (char*) tui_ctlx_keymap,
+		   vi_insertion_keymap);
+  rl_generic_bind (ISKMAP, "\\C-x", (char*) tui_ctlx_keymap,
+		   vi_movement_keymap);
...

Interesting, after entering TUI and then selecting SingleKey mode and leaving it again, we have toplevel keymap emacs_standard_keymap.

Fixed by postponing the initialization of tui_readline_standard_keymap till after tui_readline_standard_keymap:
...
   rl_initialize ();
+  tui_readline_standard_keymap = rl_get_keymap ();
...

https://sourceware.org/pipermail/gdb-patches/2025-July/219361.html

(In reply to John W. from comment #9)
> I got to wondering if somehow GDB was *stripping* my mappings on startup,
> when it configures its own readline internally.
> I haven't confirmed this, but it seems plausible given the next thing I
> tried:
> 
> (1) I added this line to my .inputrc.gdb:
> 
>     "\C-x\C-r": re-read-init-file
> 
> [That line appears twice - once under 'vi-insert' keymap, and once under
> 'vi-command']
> 
> (2) After gdb starts up (same commandline as used above), I first do C-x,C-r
> to reload my config.
> Then, after that, my C-x,C-a bindings work! I can switch to TUI, while still
> staying in vi mode.
> 

This is PR26816, fixed since the 9.1 release.