Having different completion widgets

Having different completion widgets

[Felix Rosencrantz]

I was thinking it might be useful to have different keys bound to completion
widgets with different behavior.   It doesn't seem to me that we
really provide the user with an easy way to do this without some scripting.

It seems to me that it would be possible to use the "function" field
of the context to harness zstyle to configure alternate behavior.

I tried writing a simple completion widget, _alt_complete, which can
change the function field to the name of the current widget.  Using zle -C,
and zstyle it would be possible to get a lot of different completion behaviors:

zle -C widget1 .complete-word _alt_complete
zle -C widget2 .complete-word _alt_complete
zle -C widget3 .complete-word _alt_complete
zstyle ':completion:widget1:*' completer _oldlist _complete '_correct'
'_approximate' _complete _prefix _history
zstyle ':completion:widget2:*' completer _oldlist _menu _complete  _correct
'_approximate'
zstyle ':completion:widget3:*' completer _oldlist _complete '_prefix'

_alt_complete () {
        local curcontext="$curcontext" 

        [[ -z "$curcontext" ]] && curcontext=:::
        curcontext="$WIDGET:${curcontext#*:}"

        _main_complete "$@"
}

This works fine.  Though, I was thinking that it would be possible to provide 
even more flexibility by putting a call into _main_complete with _funcall
to a hook function that could decide on how to change curcontext based on
whatever criteria the user wants.  We could provide some simple example
hook functions that would set the function field based on things like 
the current widget, the value of a shell variable,  hostname, OS, etc.
Something like:

--- _main_complete      Sun Apr 23 17:50:37 2000
***************
*** 32,37 ****
--- 32,38 ----
  typeset -U _lastdescr _comp_ignore
  
  [[ -z "$curcontext" ]] && curcontext=:::
+ _funcall - _hook_setcontext 
  
  # Special completion contexts after `~' and `='.
  
#Sample hook function
_hook_setcontext_widget ()
{
        [["$curcontext" = ":::" ]] && curcontext="$WIDGET:${curcontext#*:}"
}


It seems that this would provide an easy way to provide some useful
alternatives to the command widgets (e.g. _correct_word, most_recent_file)
using the main completion widget.

Does this seem useful?  Is it useful enough to include in the distribution?
Is there a better or more appropriate way to offer this functionality? 

-FR.


__________________________________________________
Do You Yahoo!?
Send online invitations with Yahoo! Invites.
http://invites.yahoo.com

Re: Having different completion widgets

[Sven Wischnowsky]

Felix Rosencrantz wrote:

> ...
>
> I tried writing a simple completion widget, _alt_complete, which can
> change the function field to the name of the current widget.  Using zle -C,
> and zstyle it would be possible to get a lot of different completion behaviors:
> 
> zle -C widget1 .complete-word _alt_complete
> zle -C widget2 .complete-word _alt_complete
> zle -C widget3 .complete-word _alt_complete
> zstyle ':completion:widget1:*' completer _oldlist _complete '_correct'
> '_approximate' _complete _prefix _history
> zstyle ':completion:widget2:*' completer _oldlist _menu _complete  _correct
> '_approximate'
> zstyle ':completion:widget3:*' completer _oldlist _complete '_prefix'
> 
> _alt_complete () {
>         local curcontext="$curcontext" 
> 
>         [[ -z "$curcontext" ]] && curcontext=:::
>         curcontext="$WIDGET:${curcontext#*:}"
> 
>         _main_complete "$@"
> }
> 
> This works fine.  Though, I was thinking that it would be possible to provide 
> even more flexibility by putting a call into _main_complete with _funcall
> to a hook function that could decide on how to change curcontext based on
> whatever criteria the user wants.  We could provide some simple example
> hook functions that would set the function field based on things like 
> the current widget, the value of a shell variable,  hostname, OS, etc.
>
> ...
> 
> It seems that this would provide an easy way to provide some useful
> alternatives to the command widgets (e.g. _correct_word, most_recent_file)
> using the main completion widget.
> 
> Does this seem useful?  Is it useful enough to include in the distribution?
> Is there a better or more appropriate way to offer this functionality? 

I don't have any strong feelings about this (which means I'm not
against it ;-). But I always like extensibility and I hadn't thought
about customizing key bindings more than we can do now...

Hm, I think I would either put everything into _main_complete,
something like (untested):

  [[ $#funcstack -eq 1 && $WIDGET != _main_complete ]] &&
      { _funcall ... || curcontext=... }

Or put everything, including the _funcall in the _alt_complete
bindable command. Dunno.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de