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.
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.
I am unaware of any gdb command that will enter/exit TUI mode independently of the key combination. Is there one?
Observed generally throughout 7.x and reproduced just now on 7.5.1.
> 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"
> 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
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).
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:
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.