From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23610 invoked by alias); 19 May 2015 00:44:30 -0000 Mailing-List: contact zsh-workers-help@zsh.org; run by ezmlm Precedence: bulk X-No-Archive: yes List-Id: Zsh Workers List List-Post: List-Help: X-Seq: 35196 Received: (qmail 29347 invoked from network); 19 May 2015 00:44:29 -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.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.0 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:to:subject:mime-version:content-type; bh=6hsar6kwdBp7ZXZcy4RxhrMbF/Sxl3ezo83DURqQh0E=; b=KE1Kd/80w+Gi6e/gaPG9sOhfsOR4ae9mbsGyHIFx7JLEVVxE+j2YKOqMKs2j1mANJl D/eWgmJWtbRP4BwYr1mTDHkr/9clPlumN66DAORIG/I+TWu5I+zqZZd11ECvnCuMNJ+J eTSOTT/homAWzj6nESl0FJiDP7SqMMzurlfuVwu8F84H2FSXoR/4OAVaGf/0WiQwYBgW q9Fbo/Q3UHdzYUPyE2pXYOLCA6Pw3s0DmFi0nNGMD12ZwMcfWMPm0Qa1oGXm7o1kAB0v +aQtzUl//n/gCUjvtCqqnDK9LQ2RJSPZHr1nt41BcBkbnrI/N70ecDhm5vpTw+0QfH9E V+2Q== X-Gm-Message-State: ALoCoQnPLOUISgyCxw9ixRnQrxAOBY3wPpQgQ1KdnGo9tEx/Da9oTLaEeg9ivCm9hNHfZfAqI2kj X-Received: by 10.60.37.73 with SMTP id w9mr573637oej.49.1431996267286; Mon, 18 May 2015 17:44:27 -0700 (PDT) From: Bart Schaefer Message-Id: <150518174424.ZM2337@torch.brasslantern.com> Date: Mon, 18 May 2015 17:44:23 -0700 In-Reply-To: <555A63A4.8060809@thequod.de> Comments: In reply to Daniel Hahler "Smarter matcher-list: skip previous sets" (May 19, 12:11am) References: <555A63A4.8060809@thequod.de> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: "Zsh Hackers' List" Subject: Re: Smarter matcher-list: skip previous sets MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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 be 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. -- Barton E. Schaefer