You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
autocompleteMultiselect: contextual ESC to clear filter before cancelling #519
Hey, small UX suggestion for autocompleteMultiselect (and autocomplete).
When you've typed a long filter string and want to clear it, the only option right now is holding backspace until it's gone. Pressing ESC bails out of the prompt entirely, which loses the work in progress (any tab-toggled selections, etc).
Could ESC be made contextual? Something like:
If the filter input has text → clear it
If the filter input is already empty → cancel (current behavior)
This is what fzf does, and it's also how browser address bars and most "type-ahead" UIs handle it — a single ESC tap to clear is intuitive and saves you from holding backspace through a 30-character query you no longer want.
Backspace-per-char is fine for short stuff but starts to grate when you're refining filters across a long list. In my use case I'm pruning 150 git branches via autocompleteMultiselect, and being able to filter, tab a few items, clear, filter again would feel a lot more natural than holding backspace each time.
Happy to look at a PR if it's a direction you're open to. Mostly wanted to surface the suggestion first since changing ESC semantics could surprise people who rely on the current behavior.
this seems like a good idea to me but its not quite a trivial code change.
the esc key is currently a global binding in that all prompts treat it as "cancel" in the base class. prompts don't get to decide, the global settings do.
we would basically need a way to, per-prompt, define "even though you did the cancel action, skip it this time". i.e. it isn't esc specific, it is if someone hits the key bound to cancel.
maybe a _shouldCancel or some such thing, but im not too sure yet.
also keep in mind the path prompt uses autocomplete under the hood but should behave slightly different. pressing esc on that should probably clear upto the root unless the user already deleted part of the root. e.g. it starts as /foo/bar and i type /baz, then esc should clear back to /foo/bar. unless i delete some of it, like to /foo, then it should clear the whole thing.
this needs some discussion though i think so lets not attempt it yet until there's agreement on how.
Activity
43081j commentedon Apr 29, 2026
this seems like a good idea to me but its not quite a trivial code change.
the esc key is currently a global binding in that all prompts treat it as "cancel" in the base class. prompts don't get to decide, the global settings do.
we would basically need a way to, per-prompt, define "even though you did the cancel action, skip it this time". i.e. it isn't esc specific, it is if someone hits the key bound to
cancel.maybe a
_shouldCancelor some such thing, but im not too sure yet.also keep in mind the
pathprompt uses autocomplete under the hood but should behave slightly different. pressing esc on that should probably clear upto therootunless the user already deleted part of the root. e.g. it starts as/foo/barand i type/baz, thenescshould clear back to/foo/bar. unless i delete some of it, like to/foo, then it should clear the whole thing.this needs some discussion though i think so lets not attempt it yet until there's agreement on how.