From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9935 invoked by alias); 30 Jan 2014 16:22:13 -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: 32329 Received: (qmail 28578 invoked from network); 30 Jan 2014 16:21:58 -0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 From: Bart Schaefer Message-id: <140130082206.ZM23682@torch.brasslantern.com> Date: Thu, 30 Jan 2014 08:22:06 -0800 In-reply-to: <20140130093057.6e04fa53@pwslap01u.europe.root.pri> Comments: In reply to Peter Stephenson "Re: Tests of interrupting completion, and completion_nostat_dirs" (Jan 30, 9:30am) References: <140122000435.ZM1516@torch.brasslantern.com> <140123171659.ZM19422@torch.brasslantern.com> <87iot91lp8.fsf@lwm.klanderman.net> <140125124934.ZM23767@torch.brasslantern.com> <87eh3q3g63.fsf@lwm.klanderman.net> <140129181206.ZM22813@torch.brasslantern.com> <20140130093057.6e04fa53@pwslap01u.europe.root.pri> X-Mailer: OpenZMail Classic (0.9.2 24April2005) To: zsh-workers@zsh.org Subject: Re: Tests of interrupting completion, and completion_nostat_dirs MIME-version: 1.0 Content-type: text/plain; charset=us-ascii On Jan 30, 9:30am, Peter Stephenson wrote: } Subject: Re: Tests of interrupting completion, and completion_nostat_dirs } } On Wed, 29 Jan 2014 18:12:06 -0800 } Bart Schaefer wrote: } > Hmm, to include this I'd probably want completion_nostat_dirs to be an } > autoloaded parameter in the zsh/complete module or something like that. } > It doesn't have any of those right now (the magic parameters that are } > only valid inside completion widgets are a somewhat different beast) but } > there's no reason it couldn't. } } This has traditionally been done using something that's only seen by } completion that gets passed in from above. Yes, but in this case there's a corresponding C code change to recognize the setting. } It could, for example, be something in compstate set at the top level } of _main_complete, but there are other mechanisms: the menu completion } library uses its own parameters that are set by styles, and sometimes } the effect of styles get passed into builtins which probably doesn't } fit here. I suppose the parameter *could* in fact be valid only when inside a completion widget, and it would then be up to _main_complete to copy from a zstyle into the parameter so that ztat() could see it. That would be roughly the same as the treatment of region_highlight by zle; it doesn't exist except while doing its job. Of course that would mean that compctl and/or widgets entered directly without going through _main_complete would need to do their own zstyle lookup. This is the reason that e.g. MENUSCROLL is a global parameter as well as being copied from a zstyle. } This is different from ZLE which doesn't use styles so gets configured } by straight parameters --- that's not ideal; it would be better to use } some form of namespace if we could. Right, but the completion-only scoping could stand in for that in the case of completion. The "problem" for zle is that, unless we actually make the internals aware of zstyle values at the C level, there's no guaranteed entry point where a zstyle can be referenced by shell code. (zle-line-init could serve that role now, I suppose, but then everyone needs a default zle-line-init [compare MENUSCROLL above].)