From: "Andrej Borsenkow" <borsenkow.msk@sni.de>
To: "Peter Stephenson" <pws@ibmth.df.unipi.it>, <zsh-workers@sunsite.auc.dk>
Subject: RE: zsh-3.1.5-pws-5: mixing "old" and "new" completions?
Date: Tue, 26 Jan 1999 14:52:04 +0300 [thread overview]
Message-ID: <003301be4922$4a927320$21c9ca95@mowp.siemens.ru> (raw)
In-Reply-To: <9901251327.AA32472@ibmth.df.unipi.it>
>
> I haven't got around to considering the new completion in detail, but
> it did occur to me it could be better integrated with the widget
> completion I added, i.e. zle -c and zle -C could be made more similar.
Actually, after looking at new completion examples, I really think, all
three current ways to do completion should be merged.
compctl is suitable and enough in probably 90% of all cases - and with
post-3.1.5 additions even more (am I wrong?) And if you are lucky to have
the case from remaining 10%, the cool new completion stuff is excellent tool
to extend compctl.
What I think about, is two interfaces: compctl->new completion and new
completion->compctl. That is
compctl->new completion
we need a way to call completion functions with environment set up
as expected by new functions. Unfortunately, it is incompatible with
current -K usage (as we need setup different args); do we have any
character else free? :-) O.K., let's assume for now that it is 'K'
new completion->compctl
there is already complist, that can be used to specify completion
directly. Now, what is needed, is the way to tell: "use completion,
defined for this command by compctl, if available". It is much the way,
zle -C works already. Let's call it compcall :-)
The way, in which compctl is called, must use the same convention
(arg list and variables) as new completion. This will provide for nice
recursive calls.
Consider two examples:
compctl -T -K __redirect_handler
function __redirect_handler () {
case $CONTEXT in
redirect )
do completion of redirections
;;
esac
}
This gives easy way to enable completion after redirection without actually
messing up all traditional compctl stuff. Yes, for those who already use -T,
it means some additional work ... But it only one function in this case :-)
Another one is small rewrite of new completion example:
compctl -K __precmd noglob nocorrect exec command builtin
__precmd() {
COMMAND="$1"
shift
(( CURRENT-- ))
if [[ CURRENT -eq 0 ]] then
CONTEXT=command
else
CONTEXT=argument
fi
compcall -c "$1" # -- this calls compctl completion, defined for "$1"
# -- now compctl "sees" only modified arguments,
# -- that will be passed to any functions called
}
I actually feel very uneasy about replacing compctl interface with new
stuff. But it is really a pity to not use it.
Is it hard to implement? This will give you full flexibility of all three
ways to do completion and free choice, which one to use.
/andrej
next prev parent reply other threads:[~1999-01-26 11:52 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
1999-01-25 13:15 Sven Wischnowsky
1999-01-25 13:27 ` Peter Stephenson
1999-01-26 11:52 ` Andrej Borsenkow [this message]
1999-01-28 7:06 ` Bart Schaefer
1999-01-28 11:28 ` Peter Stephenson
1999-01-28 16:31 ` Bart Schaefer
-- strict thread matches above, loose matches on Subject: below --
1999-01-28 16:57 Sven Wischnowsky
1999-01-28 14:25 Sven Wischnowsky
1999-01-28 11:59 Sven Wischnowsky
1999-01-27 15:21 Sven Wischnowsky
1999-01-27 12:25 Sven Wischnowsky
1999-01-27 15:04 ` Andrej Borsenkow
1999-01-26 13:58 Sven Wischnowsky
1999-01-25 12:11 Andrej Borsenkow
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='003301be4922$4a927320$21c9ca95@mowp.siemens.ru' \
--to=borsenkow.msk@sni.de \
--cc=pws@ibmth.df.unipi.it \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).