From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18505 invoked by alias); 14 Dec 2016 20:09:32 -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: 40190 Received: (qmail 21831 invoked from network); 14 Dec 2016 20:09:32 -0000 X-Qmail-Scanner-Diagnostics: from mail-vk0-f44.google.com by f.primenet.com.au (envelope-from , uid 7791) with qmail-scanner-2.11 (clamdscan: 0.99.2/21882. spamassassin: 3.4.1. Clear:RC:0(209.85.213.44):SA:0(0.0/5.0):. Processed in 2.031549 secs); 14 Dec 2016 20:09:32 -0000 X-Spam-Checker-Version: SpamAssassin 3.4.1 (2015-04-28) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=0.0 required=5.0 tests=RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2,SPF_PASS,T_DKIM_INVALID autolearn=unavailable autolearn_force=no version=3.4.1 X-Envelope-From: schaefer@brasslantern.com X-Qmail-Scanner-Mime-Attachments: | X-Qmail-Scanner-Zip-Files: | Received-SPF: pass (ns1.primenet.com.au: SPF record at _netblocks.google.com designates 209.85.213.44 as permitted sender) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=brasslantern-com.20150623.gappssmtp.com; s=20150623; h=from:message-id:date:in-reply-to:comments:references:in-reply-to :comments:to:subject:mime-version; bh=v0ayhQWsUElgEZnEnOAcx67qd2RtEazSbWQM1kFfEqI=; b=Hb6dw5jDF6eGubvuqixzrqJdbAjQ6RB+5J6oBacfEn2q13ZCVrz7nl6RNvKvtKin/j TNB/ARd+9ZKINO5/pjyGxYJWH/vlnGr4WFg2Q/37DDNWJugf+kcBWZF3TEzCE0Oa+ZRY V4CKUZlnWPGXFwcl9HpLhv3oYAfV03u0dT4QsLIN+OCpi37e7wx1i1lZGr7qmx/wucGe lhPCw20PyzD7YU3P4MIV2+9T+rZLPgxHrI7kpEf9cUO+GS22CsIxITqK34YHXWdZxIgf dIIV7mymguyb+ONvTRyEfAlZNVPzQfCnBaAOAIDa557vPDoGAPeNVqfc+Epd6EdTEmHQ B6yQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:date:in-reply-to:comments :references:in-reply-to:comments:to:subject:mime-version; bh=v0ayhQWsUElgEZnEnOAcx67qd2RtEazSbWQM1kFfEqI=; b=enyNSic40Y6yuGpfmDJ3hSwbwlJNGvHyhFQo1BwRjVuvXhrkzjtyQpaXZqFZi6I7Ga tuhm13FVD576L2f4NVIPuQsinAzwzepHA6yp0Vwc/ZJO07PxJdRHknC6/iZRbqggewrs V1a51tJjopLJs75YBftKa6tcwN/o7sYWo519SKBTQIJooEgx76r3/FPfa17neVtO9jAA UBxV6vQy+T2de0Q3wc9NjoadUoDB2R9JP3ypZKXoD55oNgeE7kh7y5eGgjC/Jf932ZWG Ydmv4YDht6sAFkmhD3lNJkKCOW4dU82YPFt0Xvonh45Lg1JJJ7W9xG6m9VRd+BA17S6s LRLQ== X-Gm-Message-State: AKaTC02bPULRPKOfYwgdpns37dB0b2u6wlRFwWo0Yd6giTybdPVo51yWpa/HLiU5LHXUPg== X-Received: by 10.31.228.71 with SMTP id b68mr46754689vkh.163.1481746162088; Wed, 14 Dec 2016 12:09:22 -0800 (PST) From: Bart Schaefer Message-Id: <161214120950.ZM10412@torch.brasslantern.com> Date: Wed, 14 Dec 2016 12:09:50 -0800 In-Reply-To: <19089.1481715508@hydra.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: caching mechanism and Re: PATCH Completion for _yum" (Dec 14, 12:38pm) References: <61b3fb7c-4de6-d8da-29b4-b3802d98b162@mathphys.fsk.uni-heidelberg.de> <20161027013054.GA15799@fujitsu.shahaf.local2> <484fa75d-9361-df92-06b4-54fad37231f4@mathphys.fsk.uni-heidelberg.de> <98208.1478792966@hydra.kiddle.eu> <765413af-36a5-9afb-dd8a-7e1a39d05dde@mathphys.fsk.uni-heidelberg.de> <31607.1478915523@hydra.kiddle.eu> <75905.1479841546@hydra.kiddle.eu> <6472.1481623850@hydra.kiddle.eu> <161213083842.ZM21919@torch.brasslantern.com> <161213092141.ZM22063@torch.brasslantern.com> <19089.1481715508@hydra.kiddle.eu> <35304.1481727834@hydra.kiddle.eu> <4C0CE80C-4534-4118-8AA6-022FF9FFCF05@kba.biglobe.ne.jp> <46860.1481737601@hydra.kiddle.eu> In-Reply-To: <46860.1481737601@hydra.kiddle.eu> Comments: In reply to Oliver Kiddle "Re: caching mechanism and Re: PATCH Completion for _yum" (Dec 14, 6:46pm) X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: caching mechanism and Re: PATCH Completion for _yum MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii On Dec 14, 12:38pm, Oliver Kiddle wrote: } } > > Whether we want to be keeping caches also in a global variable is a } > > different question } } > keeping the data in a variable may not be a good idea. } } I'm uneasy about it either way. What about someone who wants to set } use-cache to false? It also seems a pity not to keep the variable } between _complete and various runs of _correct/_approximate. Well, the point of it being a global is that it *is* kept, not just between _complete and others, but for the whole shell session, unless overwritten by _retrieve_cache, which should only happen if the cache is invalid. The basic idea -- take any variable the caller wants, and stuff its value in a file in a quickly-reloadable format -- is a good one; I just think the way the styles are used to configure it is a lot more convoluted than necessary. } Sven also stated: } We decided some time ago that they [completion functions] } shouldn't set styles themselves, only look them up. } } That was apparently ignored. There are a couple of cases where it's more convenient to do a test- and-set of a style rather than having to repeat the default values in multiple places, if you know the order in which the style calls will be made. But I would say that normally that should happen only in the circumstance where an autoload file is first setting the style and then redefining its own function, so the setting happens only once. } Another option would be to deprecate the old mechanism completely? I've no problem with that, either -- though more recently a lot of work was put into making the cache file write/read as fast as possible, so it would be nice to preserve that.