Getting "complete" and "menu-complete" to work together

Viewed 16890

I found out that the Bash shell supports a type of autocompletion that is different from the "traditional" autocompletion, where all possibilities get listed on the following line.

With the "traditional" autocompletion, if I type ch and then press the Tab key, I get something like:

$ ch
chacl  chgrp  chmod  chown  chvt

But if I add the following line to my /etc/inputrc (which remaps the Tab key to the built-in menu-complete function):

Tab: menu-complete

then the behavior of the shell changes: the word to be completed is replaced "inline" with a single match from the list of possible completions, and if I press the Tab key again, the word gets replaced with the next match.

I found this useful, but I still wanted to keep the traditional autocompletion and have it bound to the key combination Ctrl + Tab. So I added the following line to my /etc/inputrc file, according to what the readline library documentation suggests:

Ctrl-Tab: complete

However, adding this line only seems to make both Tab and Ctrl-Tab call the traditional complete function.

Does anyone know what I am doing wrong?

Thanks in advance!

5 Answers

I have ShiftTab bound to menu-complete-backward, so it goes back one step if I skipped the right completion, and I've mapped Ctrlq to complete, so if there are several possible completions I hit Ctrlq to list them without having to cycle through them.

# Make Tab cycle between possible completions
# Cycle forward: Tab
# Cycle backward: Shift-Tab

TAB: menu-complete
"\e[Z": menu-complete-backward

# Make C-q display the list of possible completions

Control-q: complete

# Display the list of matches when no further completion is possible

set show-all-if-unmodified on

Edit: Ctrlq is bound to quoted-insert by default, that is, it tells the shell to take the next key literally. quoted-insert is also bound to Ctrlv, so you don't lose that functionality if you rebind Ctrlq. Anyway, I've found that AltESC also works, by default, for showing the possible completions (as far as I can tell it is equivalent to TAB); note that it may be seized by Gnome, then either double press ESC or rebind "Switch windows directly" in Settings → Devices → Keyboard → Navigation.

The following should achieve what you're looking for (if I understand correctly!)

In your .inputrc

# display all possible matches for an ambiguous pattern at first tab
set show-all-if-ambiguous on

# next tab(s) will cycle through matches
TAB: menu-complete
# shift tab cycles backward
"\e[Z": menu-complete-backward

Where to start, if you can or cant do this is dependent your keyboard and your drivers and there isn't one catch all answer. Each key press and release generates a sequenced key pair (key down and release) (scancode) these codes are then translated by the kernel into keycodes for example on my laptop keyboard 0x3a 0xba are translated to keycode 15 (down and up) these are then translated into actions such as return letter c a / you can assign actions to keysyms using the keycode/hex/binary/octal notation which codes match which letters is determined by the kernel translation table which is fairly standardized, however the first part signal that's translated to keycodes is different for most keyboards.

Continuing with the earlier example for me shift tab (and alt and control and any combination) produce keycode 15 however in hex it produces 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a 0x2a and this is because shift alt and control are special keys (modifiers) these multiply out against the keycodes and fill out the dumpkeys table the kernel is limited to the number of assignments as well this is determined by your choice of keymap and shares resources with your terminal colors (if your char set its defined above the threshold it limits your terminal color scope). And this all goes out the window if your in an xserver and has a whole new system. Most of these things can be changed,modified and manipulated by the user and programs installed. My point to all this is to emphasize that there is no catch all for the mapping of the tab key and its going to vary keyboard drivers to kbd drivers (now if you find a solution that happens to work for you excellent :)) but chances are it won't be portable and might not work if you change keyboards and might not translate between xserver and tui. What i recommend is learning the steps to modify your kbd on the go.

will give you the decimal octal hex notation for a key press on the same line

--full-table -1 >> keytable 

will give you a documented with your full list of keycode->keysym pairing in a format that will give you a better picture of your layout and from there you can either use loadkey to change a keys value or ad an entry in .inputrc or your main rc file. You can also create a custom key.map file. Further escape sequence translation is determined by the "$TERM" variable and each virtual terminal emulator can be different

infocmp "$TERM"

will give you a list of your terminal escape sequences

Resources:

https://man7.org/linux/man-pages/man4/console_codes.4.html

https://www.gnu.org/software/screen/manual/html_node/Input-Translation.html

http://kbd-project.org/docs/scancodes/scancodes.html

https://www.vt100.net/

So to sum up. Your keyboard drivers Your kemap choice Your virtual terminal emulator and your kernel form the backbone of remapping dificult keys (tab/s-tab/a-tab)

Related