Zsh Mailing List Archive
Messages sorted by:
Reverse Date,
Date,
Thread,
Author
Re: Obscure issues with "zle complete-word ..."
- X-seq: zsh-workers 8341
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: Obscure issues with "zle complete-word ..."
- Date: Wed, 20 Oct 1999 15:42:08 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Wed, 20 Oct 1999 06:32:12 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
Bart Schaefer wrote:
> At the top of _history_complete_word is the following test:
>
> if [[ $WIDGET = *newer ]]; then
> direction=older
> else
> direction=newer
> fi
>
> However, the value of $WIDGET matches neither *newer nor *older when the
> function is called via
>
> zle complete-word _history_complete_word
>
> As it is, for example, when placed in compconfig[incremental_completer]
> for use by incremental-complete-word.
>
> I've just erased and retyped this next paragraph four times, so I guess
> I really don't know what I expect to be done about this. I suppose the
> only way is to create two functions as well as two widgets.
Which reminds me that I wanted to suggest to move the information
gathering stage of `_h_c_w' into a completion function (with the trick
from `_first' triggered by at least one config key, please), say
`_history'. That would then be a possible value to use in
`incremental_completer'. Then we should document that due to the
cunning consistence in the meaning of the return value of completers
and completion functions (yes, ther *is* a certain difference -- even
if only in concept), names of completion functions may also be given
as arguments to `_main_complete'. Not only completers. Or we just say
that completion functions may act as simple completers. Hm, yes, that
may be better.
> This caused me to notice something else; the documentation for the "zle"
> command says:
>
> WIDGET [ -n NUM ] [ -N ] ARGS ...
> Invoke the specified widget. This can only be done when ZLE
> is active; normally this will be within a user-defined widget.
>
> [...]
>
> Any further arguments will be passed to the widget. If it is
> a shell function, these are passed down as positional
> parameters; for builtin widgets it is up to the widget in
> question what it does with them. Currently arguments are
> only handled by the incremental-search commands, the
> history-search-forward and -backward and the correspeonding
> functions prefixed by vi-, and by universal-argument.
>
> Clearly complete-word (and other builtin completion widgets?) also will
> accept arguments.
Well, all widgets `accept' arguments. It's just that most them happily
ignore them. The builtin completion widgets, for example, do that. The
`complete-word' above is really the one defined in `compinit', line
429. So it is a user defined one and hence covered by the paragraph
above.
> Are there other widgets that aren't mentioned?
I think not, there are only the examples from Peter's and my merged
implementations for the stuff. People who like to do zle magic might
want to start thinking about other widgets which we might want to give
arguments, though (I think I mentioned that when I posted my stuff).
> Is it
> time to start documenting the arguments in the subsctions on "Standard
> Widgets"?
Yes, I've been thinking about that, too. Especially if we find other
widgets for which arguments may be interesting to have.
But then, I also like to think about moving widgets into (or replacing
widgets with) shell code.
Bye
Sven
--
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by:
Reverse Date,
Date,
Thread,
Author