Re: menuselect and history

Re: menuselect and history

[Oliver Kiddle]

[redirected to -workers]

Bart wrote:
> On Apr 19, 11:52am, Matthias Kopfermann wrote:
> > 
> > i just wondered whether it wouldn't be very cool if menuselect was
> > useable with historylines.
> 
> --- 8< --- snip --- 8< ---
> #compdef -k menu-select ^X:

Very nice.

> emulate -L zsh
> zmodload -i zsh/parameter || return 1

I would tend to be inclined to use _generic to avoid needing such setup
code. Also makes it a lot more configurable. Trouble is, that you need
to manually define:
  zle -C history-lines menu-complete _generic
  zstyle ':completion:history-lines::::' completer _history_lines
  bindkey '^X:' history-lines

I wonder if we should make #compdef -k, make widgets go through
_generic somehow. It isn't ideal that with #compdef -k, the function is
effectively operating outside of compsys, using raw compwid.

Oliver

Re: menuselect and history

[Bart Schaefer]

On Apr 19,  7:20pm, Oliver Kiddle wrote:
> 
> Bart wrote:
> > emulate -L zsh
> > zmodload -i zsh/parameter || return 1
> 
> I would tend to be inclined to use _generic to avoid needing such setup
> code.

Does that succeed in forcing menu-selection to always be used?  Normal
menu completion can't work here because you're completing multiple words
simultaneously -- one word (the command) is being replaced by many (the
whole command line, possibly many lines), and that confuses the heck out
of the completion system because the semantic context isn't the same in
all the "matches."  Hence this ...
> effectively operating outside of compsys, using raw compwid.
... is, in this case, partly intentional.

> I wonder if we should make #compdef -k, make widgets go through
> _generic somehow.

That can be solved by having the function redefine itself like so:

--- 8< --- snip --- 8< ---
#compdef -k menu-select ^X:
zle -C history-select menu-select _generic
zstyle ':completion:history-select::::' completer _history_select
bindkey '^X:' history-select

_history_select() {
  # ... my original function body here ...
}

_generic "$@"
--- 8< --- snip --- 8< ---

Presumably `compdef' could be fixed up to do the equivalent when passed
the correct options.  I'd recommend leaving -k as it is and adding a new
option to automatically apply the _generic wrapper.

Re: menuselect and history

[Oliver Kiddle]

Bart wrote:

> Does that succeed in forcing menu-selection to always be used?  Normal

It depends on your menu style just like normal completion.

> menu completion can't work here because you're completing multiple words

I don't think there's a way round that. It's unfortunate for a number
of reasons that completion forces initial splitting on shell words.

> That can be solved by having the function redefine itself like so:
> 
> --- 8< --- snip --- 8< ---
> #compdef -k menu-select ^X:
> zle -C history-select menu-select _generic
> zstyle ':completion:history-select::::' completer _history_select

The trouble with this is that it is forcing a particular completer
style on you. Often it is useful to be able to add other completers
like _menu and _match to the list. Though you could contrive a more
specific context, I don't really like the idea of defining styles
behind people's back like this. The fact that they are defined when the
widget is invoked makes this even worse. It makes it very hard if you
want to override the settings, perhaps to use different key bindings
from the default.

I'd prefer to find another way to communicate the default completer to
_main_complete. We could keep them in an associative array or could
even use _${WIDGET/-/_}. The other problem is knowing when to use the
default completer list and when to use the completer style. All too
often, zstyle will return the user's default completer.

It seems that setting up sensible defaults while maintaining
configurability is going to be hard.

> Presumably `compdef' could be fixed up to do the equivalent when passed
> the correct options.  I'd recommend leaving -k as it is and adding a new
> option to automatically apply the _generic wrapper.

Yes a new option is probably necessary to maintain backward
compatibility.

Oliver