Is it already possible to configure some of this in zsh? http://zsh.sourceforge.net/Doc/Release/Completion-System.html
Tried the following:
-
expand ❓: If one of its values is the string ‘suffix’, matching names for components after the first ambiguous one will also be added. This means that the resulting string is the longest unambiguous string possible. However, menu completion can be used to cycle through all matches.
$ zstyle ':completion:*' expand 'prefix' 'suffix' $ zstyle ':completion::complete:*' expand 'prefix' 'suffix'
-> No effect.
-
file-sort ✅: The standard filename completion function uses this style without a tag to determine in which order the names should be listed; menu completion will cycle through them in the same order. The possible values are: ‘size’ to sort by the size of the file; ‘links’ to sort by the number of links to the file; ‘modification’ (or ‘time’ or ‘date’) to sort by the last modification time; ‘access’ to sort by the last access time; and ‘inode’ (or ‘change’) to sort by the last inode change time. If the style is set to any other value, or is unset, files will be sorted alphabetically by name. If the value contains the string ‘reverse’, sorting is done in the opposite order. If the value contains the string ‘follow’, timestamps are associated with the targets of symbolic links; the default is to use the timestamps of the links themselves.
$ zstyle ':completion:*' file-sort access
-> Will use this to sort by most recently accessed (e.g. do
cat foo.b
to make it the first completion item). -
force-list ❓: This forces a list of completions to be shown at any point where listing is done, even in cases where the list would usually be suppressed. For example, normally the list is only shown if there are at least two different matches. By setting this style to ‘always’, the list will always be shown, even if there is only a single match that will immediately be accepted. The style may also be set to a number. In this case the list will be shown if there are at least that many matches, even if they would all insert the same string. This style is tested for the default tag as well as for each tag valid for the current completion. Hence the listing can be forced only for certain types of match.
$ zstyle ':completion:*' force-list 'always' $ zstyle ':completion:*:default' force-list 'always'
-> No effect.
-
menu ✅: If this is ‘true’ in the context of any of the tags defined for the current completion menu completion will be used. If the value contains the string ‘select’, menu selection will be started unconditionally. The word ‘interactive’ in the value causes interactive mode to be entered immediately when menu selection is started; see The zsh/complist Module for a description of interactive mode. Including the string ‘search’ does the same for incremental search mode.
$ zstyle ':completion:*' menu 'true' 'select' 'interactive' 'search'
Has no effect, but the following does (tried
interactive
but didn't like it because it didn't complete and cycle with<TAB>
):$ zstyle ':completion:*:default' menu 'yes' 'search'
Before:
v fo
<TAB>
->v foo.
,<TAB>
-> file menu,<TAB>
-> select first entry:v foo.a
,<CR>
accepts completion,<CR>
executes command. With this:v fo
<TAB>
->v foo.a
with interactive search prompt (typingb
will selectfoo.b
,<TAB>
cycles through results),<CR>
ends isearch,<CR>
accepts completion,<CR>
executes command.How to get rid of additional
<CR>
?man zshmodules
:accept-line
only leaves incremental search, going back to the normal menu selection mode. [...] For example, the widget.accept-line
has the effect of leaving menu selection and accepting the entire command line.bindkey ^J .accept-line
(https://unix.stackexchange.com/questions/280368/how-can-i-use-a-key-other-than-enter-to-exit-zshs-completion-menu-widget) has no effect. -
setopt menu_complete
✅: https://unix.stackexchange.com/questions/12288/zsh-insert-completion-on-first-tab-even-if-ambiguous?rq=1 Works, simplest solution:v fo
,<TAB>
->v foo.a
with open menu withfoo.a
selected (<TAB>
cycles),<CR>
accepts completion,<CR>
executes command.^O
accepts completion and executes command.bindkey
: "^O" accept-line-and-down-historybindkey -M menuselect '^J' .accept-line
also works (^M
orspace
can then still be used to insert completion w/o executing).
Additional options:
$ zstyle ':completion:*' show-ambiguity 'true'
If the zsh/complist module is loaded, this style can be used to highlight the first ambiguous character in completion lists. The value is either a color indication such as those supported by the list-colors style or, with a value of ‘true’, a default of underlining is selected. The highlighting is only applied if the completion display strings correspond to the actual matches.
n::default' menu 'yes' 'search' n::complete:' expand 'prefix' 'suffix' Like for git: show some icon if make would have something to do. Problem: only works if for non-phony targets.