zsh-workers
 help / color / mirror / code / Atom feed
From: Bart Schaefer <schaefer@brasslantern.com>
To: Zsh <zsh-workers@sunsite.dk>
Subject: Re: Tags in function files
Date: Thu, 18 Sep 2003 03:44:47 +0000	[thread overview]
Message-ID: <1030918034447.ZM6431@candle.brasslantern.com> (raw)
In-Reply-To: <20030917193709.GA283@DervishD>

[reordering things a little ...]

On Sep 17,  9:37pm, DervishD wrote:
>
>     My problem with the compsys documentation is that I don't know
> which parameters, tags and the like are defined by compsys and which
> ones are controled by Zsh guts ;)) I'm learning, slowly but surely ;)

If it's in "man zshcompwid" (info doc, Completion Widgets section) then
it's an internal parameter.  If it's in "man zshcompsys" (Completion
System section) then it's created by _main_complete or one of the helper
functions it calls.

Nearly all the parameters that you're supposed to access directly are
internal; parameters of compsys are mostly "hidden" behind zstyles, or
commands such as compdef.

Conversely, all zstyles, tags, etc. are defined by compsys.  There are
no internally-defined tags.  (There are several builtins to manipulate
them [for speed], but you're not supposed to need to know that.)

So if you're not using compinit, you can ignore anything that's said
about styles and tags.

>     OK, now all makes sense. I was testing with a dummy widget (NOT a
> completion one...) and I was able to use 'zle complete-word' inside
> my widget, but I couldn't use '$words' (it expanded to nothing). On
> the other hand, I created a dummy completion widget with zle -C but
> then I wasn't able to use the predefined widgets inside.

Right.  ZLE is separate from the collection of completion modules.  When
a completion widget is invoked, zsh/zle gives control to zsh/complete,
and won't accept control back again until the completion widget returns.
Thus you can begin a completion from a normal widget, but you can't call
back to a normal widget from a completion.  (The normal widget can keep
going after the completion finishes, but that's something different.)

However, please note that there are no predefined completion widgets!

There are only predefined completion _behaviors_ which happen to be
described by a set of widget names.  The competion widgets that _used_
to be predefined are now supplied by the zsh/compctl module, which has
to be loaded in order for those widgets to do anything.

As it turns out, if you attempt to use completion without first defining
at least one widget, zsh automatically loads zsh/compctl just so that
something sensible will happen.  The illusion of predefined completion
widgets is maintained, but it really is an illusion.

> Namely something like this:
> 
> my_comp () {
>     zle .complete-word
> }
> 
> zle -C dummycomp complete-word my_comp

This sort of thing is why "compcall" (from the zsh/compctl module) is
provided.  You want:

    zmodload -i zsh/compctl
    my_comp () {
	compcall -D
    }

The behavior of "compcall" is selected by the 2nd argument of "zle -C";
you can't switch from complete-word to expand-or-complete in midstream
(except in so far as poking into the compstate parameter allows).

> I would like to be able to last-resort to some
> predefined completion widget, or even call some zle widget to move
> the cursor, retrieve the story, clean the command line, etc... That
> is, using some of the zle facilities inside my completion widget.

Unfortunately you can't do the latter of those directly from within
the completion widget.  What you can do, I believe (having never tried
it myself), is something like this:

    my_comp_wrapper () {
	local some_variable_set_by_my_comp_on_failure
	zle dummycomp	# Invoke your completion, let it return
	if [[ -n $some_variable_set_by_my_comp_on_failure ]]
	then
	    # move the cursor, retrieve the story, clean the command line
	fi
    }
    zle -N my_comp_wrapper
    bindkey '^O' my_comp_wrapper

Just remember NOT to declare some_variable_set_by_my_comp_on_failure as
a local in my_comp.  You want it to modify its caller's local.


      reply	other threads:[~2003-09-18  3:44 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-09-16 20:35 DervishD
2003-09-17  7:48 ` Oliver Kiddle
2003-09-17  8:37   ` DervishD
2003-09-17 16:30     ` Bart Schaefer
2003-09-17 19:37       ` DervishD
2003-09-18  3:44         ` Bart Schaefer [this message]

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=1030918034447.ZM6431@candle.brasslantern.com \
    --to=schaefer@brasslantern.com \
    --cc=zsh-workers@sunsite.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).