Steps to reproduce: 1. Replace contents of ~/.inputrc with the single line "Control-j: menu-complete". 2. Open gdb. 3. Enter "layout asm" and press Enter. 4. Type "help" and press Enter. Expected behavior: the help menu should appear. Actual behavior: the prompt begins menu-completing through "help <", "help >", "help -", "help !", "help +", "help actions", "help add-auto-load-safe-path", etc. Hypothesis: because J is ASCII 0x4a, Ctrl-J is 0x4a & ~(0x40), and so a newline character 0x0a is incorrectly triggering menu-complete. Note that this behavior does not impact other programs that use readline, like bash(1) and python(1). This is GNU gdb (Ubuntu 7.7.1-0ubuntu5~14.04.2) 7.7.1.
I am not sure I understand this bug. It seems to me that C-j is enter. So, if you rebind it to menu-complete, that is what you should expect to get. Maybe the weird part is that "layout asm" works?
Yes, the ASCII for C-j is the same as the ASCII for Enter. But in other TUI applications, C-j can be bound separately. That is, other applications that use readline and .inputrc do not suffer from this problem. With "Control-j: menu-complete", pressing C-j in a Python REPL performs menu completion, while pressing Enter executes the current statement. In a Bash shell, pressing C-j performs menu completion, while pressing Enter executes the current command line. (The same is true for applications like Vim: you can "inoremap <C-j>" without affecting the behavior of Enter. But Vim operates in raw mode and does not use readline, so the comparison is less apt.) It seems that GDB is the odd one out here, no?
Thanks for the explanation. I played with a simple readline application and .inputrc. For me, the enter key is bound to C-m, not C-j, which explains what you are seeing in those other applications.
Confirmed.
Confirmed; good catch. It seems that in GDB's default layout Enter is bound to C-m, whereas in layout asm it is bound to C-j (and not also C-m). It would be nice to make these consistent so that users can bind one or the other that works in all cases, preferably fixing layout asm to be consistent with other readline applications.
This line in tui-io.c: ch = wgetch (w); ... return 10 when I press enter and when I press C-j. This happens because tui_enable calls "nl()". "nonl()" (love those curses API names) is needed to differentiate these -- but it also affects output. Wrapping the wgetch call with this seems to help.
I sent a patch to gdb-patches.
Fixed by commit 7a9569281a63e472750e3b7b481e2cdf5c931ed8, but I typod the bug # and so it didn't show up here.
I think I may need to back out this change, since it causes a regression: now after pressing enter, a newline is not emitted, so the command output starts on the same line as the input. Alternatively maybe there is a way to get the enter handler to print the newline. I haven't looked into this yet.
Re-fixed.