From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <zsh-workers-return-35220-mason-zsh=primenet.com.au@zsh.org>
Received: (qmail 28996 invoked by alias); 19 May 2015 08:50:17 -0000
Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm
Precedence: bulk
X-No-Archive: yes
List-Id: Zsh Workers List <zsh-workers.zsh.org>
List-Post: <mailto:zsh-workers@zsh.org>
List-Help: <mailto:zsh-workers-help@zsh.org>
X-Seq: 35220
Received: (qmail 1886 invoked from network); 19 May 2015 08:50:16 -0000
X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on f.primenet.com.au
X-Spam-Level: 
X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED,
	DKIM_VALID,DKIM_VALID_AU autolearn=ham autolearn_force=no version=3.4.0
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=thequod.de; h=
	content-transfer-encoding:content-type:content-type:in-reply-to
	:references:subject:subject:mime-version:user-agent:from:from
	:date:date:message-id:received:received; s=postfix2; t=
	1432025414; bh=SuZcMyjcr4NHc1qC3C7gHjwhbSejCKuhEYmoJ7wUlC8=; b=a
	+txT2YG7wsddnz0WvoQ7uYfBLdiYQVpyN188CPecMOIaqeIpIGy9PiOSlmPXqWcX
	YuZ4V2A+CwG00QuN4ELlK5tFxXuZsyKGli119GxAWURi47bxgo6i2gmwt0HGRqu9
	Wis00PpAa1E+aeEBnVYSGRUg85pYo0z8uPQAAEXW68=
Message-ID: <555AF946.6010202@thequod.de>
Date: Tue, 19 May 2015 10:50:14 +0200
From: Daniel Hahler <genml+zsh-workers@thequod.de>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.6.0
MIME-Version: 1.0
To: Zsh Hackers' List <zsh-workers@zsh.org>
Subject: Re: Smarter matcher-list: skip previous sets
References: <555A63A4.8060809@thequod.de> <150518174424.ZM2337@torch.brasslantern.com>
In-Reply-To: <150518174424.ZM2337@torch.brasslantern.com>
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: 7bit

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 19.05.2015 02:44, Bart Schaefer wrote:
> On May 19, 12:11am, Daniel Hahler wrote:
> }
> } I've noticed that my matcher-list setup causes a (possibly expensive)
> } completion function to be called multiple times, although the input was
> } not changed by the matcher-list substitution.
> }
> } I think it would be smart if these calls would be skipped in case the
> } input has not changed (because it was all lower-case in the beginning).
>
> Unfortunately the matcher-list is handled as a loop in the shell code in
> _main_complete, which has no way to tell whether the "input" is or is not
> "changed" by any particular matcher.  You're assuming an implementation
> of matchers that doesn't (ahem) match what actually happens internally.
>
> Matchers don't "change" the input in any way; they alter the comparison
> of the input to the set of possible results, and each such comparison is
> independent of those that preceded it.  The *output* may be changed based
> on which elements of the result set are selected.

But is it necessary then to call the completion function multiple times?
Couldn't the matchers just loop over the result that has been collected
once?

If I understand it correctly, the possible results would be the same
every time?  (at least that's the case for the expensive completion
function, where I've noticed it).

Where is the $_matcher used?
Is it in Completion/Base/Core/_description, in the opts to compadd?

What would be a possible solution to improve handling with many
completers/matchers?


Regards,
Daniel.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iD8DBQFVWvlGfAK/hT/mPgARAigUAKCiubdTM7JYYRlA1d2muHFm4O/v0ACg/IvO
xHLF7p+ny8de/8RwASKHMjc=
=AsuP
-----END PGP SIGNATURE-----