Clear/exit keyboard bindings

[theol0403]

What do you want?

When editing on the command line, I sometimes want to:

1. cancel browsing the completions and return to the original uncompleted text
2. nuke the whole line and start over

My desired bindings for this are:

1. Esc: exit the completion selector and return the prompt to the state before tab was pressed (assuming menu-select)
2. CTRL-C: exit everything and return to an empty prompt

Currently, CTRL-C takes 1-4 presses to clear the prompt:

1. (Occasional) If some running query needs to abort (prints an error)
2. (Bug) If esc was pressed while in completion selector
3. Exit completion selector
4. Clear text

Coincidentally, other than item 1 and 2, which are bugs, that behaviour is what I am looking for to map Esc to (exit selector and return to untouched input).

Currently, Esc does nothing (and seems to add to the number of CTRL-C required to clear), and CTRL-C is a bad experience.

I'm not sure if this is something I can implement in my config, as I don't really know how to work with zsh bindings, but I feel like this might need to be something that is added to the plugin.

Thanks a lot for this awesome tool!

[marlonrichert]

When editing on the command line, I sometimes want to:

1. cancel browsing the completions and return to the original uncompleted text

Use the send-break widget, bound to ^G by default.

2. nuke the whole line and start over

Use the kill-whole-line widget, bound to ^U by default.

My desired bindings for this are:

1. Esc: exit the completion selector and return the prompt to the state before tab was pressed (assuming menu-select)

That would have a lot of unwanted, undesirable side effects. ^[ is used in a lot of terminal codes, including those produced by many other keys.

2. CTRL-C: exit everything and return to an empty prompt

That's not possible. Zsh does not let you change the behavior of ^C.

Note that all of this is handled by the Zsh Line Editor, and not by zsh-autocomplete. If you have more questions about this, I would recommend asking on the Zsh mailing list, on the Zsh subreddit or on one of the Stack Exchange sites.

[theol0403]

Thank you for your quick response, and sorry for my inexperience with this.

Even though ^C is not customizable, the default behaviour of returning to the prompt is quite close to my desired behaviour - it just has some annoyances. On some long completions, the following happens:

https://asciinema.org/a/jC2yE5OaQ0hURvxU9QywhMVpI

This is going:

1. sudo
2. tab tab tab
3. ^C
4. n (at possibilities prompt)
5. ^C to clear the zsh suggestions

I found #142, but I imagine it is unrelated.
I don't know if this is something you can fix, but if steps 3 to 5 could be shortened, it would be awesome.

Thanks!

[marlonrichert]

Like I said, try pressing ^G instead of ^C.

[theol0403]

Yep, that works well, thanks. I guess I just think that ^C should be usable for its expected purpose, and not completely unusable when using this plugin. If this is not possible for you to fix, I understand. Thanks

[marlonrichert]

Try putting

zstyle ':autocomplete:tab:*' widget-style menu-complete

in your .zshrc file and see if that makes it any better for you.

[theol0403]

That works well! Now, CTRL-C will kill the line first try. It is nice to see the menu selection, however...

[marlonrichert]

You can always activate menu selection by pressing ↓ Down.

[theol0403]

Actually, it seems like the issue still happens with bindkey '^N' send-break in menu-select. The terminal output looks identical to the asciinema I showed yesterday (except I press ^N instead of ^C). kill-whole-line works well, but send-break causes the possibilities prompt to show.

[marlonrichert]

Sorry, I forgot to watch the asciinema. You should never get to see zsh: do you wish to see all 3484 possibilities (1743 lines)?. That's definitely a bug, but I cannot reproduce it.

Can you please make me a reproducible test case with the bug report template below? If I cannot reproduce it, then I cannot fix it.

 # Make sure you always test with the `main` branch.
$ git -C /path/to/zsh-autocomplete switch main

# Update to the latest commit.
$ git -C /path/to/zsh-autocomplete pull

# Create a temp dir and enter it.
$ cd $(mktemp -d)

# Restart Zsh without config files in this dir.
$ ZDOTDIR=$PWD HOME=$PWD exec zsh -f

# Source the plugin.
% source /path/to/zsh-autocomplete/zsh-autocomplete.plugin.zsh

# Test and document the steps that reproduce the problem.
% <insert your steps to reproduce here>

[theol0403]

I have configured down to history-substring-search-down, so I don't know if it is possible to make it work to navigate the selection. I was hoping to use tab to navigate.

[marlonrichert]

If you're using zsh-autocomplete, then you don't really need history-substring-search. You can just press ↑ Up to view and select from the 16 most recent history substring matches.

[theol0403]

I'm super confused. My .zshrc is currently

zstyle ':autocomplete:*' min-input 4
zstyle ':autocomplete:tab:*' insert-unambiguous yes
zstyle ':autocomplete:tab:*' widget-style menu-select
zstyle ':autocomplete:*:too-many-matches' message ''

source /home/theol/.oh-my-zsh/custom/plugins/zsh-autocomplete/zsh-autocomplete.plugin.zsh
source /home/theol/.oh-my-zsh/custom/plugins/zsh-vim-mode/zsh-vim-mode.plugin.zsh

When I open a new zsh shell, I can reproduce the issue (sudo tab tab ^C).

• I need to press tab twice for the issue to happen
• Unsourcing zsh-vim-mode removes the problem
• Removing https://github.com/softmoth/zsh-vim-mode/blob/master/zsh-vim-mode.plugin.zsh#L304 solves the problem

However, the thing that really confuses me is that when I follow your above steps:

• cd $(mktemp -d)
• ZDOTDIR=$PWD HOME=$PWD exec zsh -f
• source /home/theol/.zshrc

The problem does not happen at all.

There must be some caching going on, but I can't figure out where. I've tried deleting zcompdump and ~/.cache/zsh to no avail.

[marlonrichert]

zsh -f disables the loading of all Zsh config files, which includes these global, non-user-specific config files:

• /etc/zshenv
• /etc/zprofile
• /etc/zshrc
• /etc/zlogin

Have a look in those files to see if there's anything happening there that could be interfering.

[theol0403]

Regardless, commenting out the function at that line is a workaround for the problem. Now, everything works quite well.
Currently:

• ^U kill line
• ^C send-break (or equivalent)

However, there is just one last bug. If I type something that takes some time to query completions, and then instantly press ^C, I can occasionally cause it to print:

sudo dnf list
Killed by signal in _dnf after 0s

This is what I meant in the OP by "(Occasional) If some running query needs to abort (prints an error)". This does not happen with a custom send-break binding. I don't know if this is something that is fixable, but it is the last thing preventing me from being able to use ^C.

[marlonrichert]

That's completely normal behavior for ^C. It's output by this line in Zsh's _main_complete() function:
https://github.com/zsh-users/zsh/blob/f4a248f9d38dc02d65610395f4c7f9a95a5d6612/Completion/Base/Core/_main_complete#L164