From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13450 invoked by alias); 1 Jun 2013 20:19:01 -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: 31443 Received: (qmail 8983 invoked from network); 1 Jun 2013 20:18:46 -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=-2.6 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 Received-SPF: neutral (ns1.primenet.com.au: 209.85.212.182 is neither permitted nor denied by SPF record at ntlworld.com) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=x-proxyuser-ip:date:from:to:subject:message-id:in-reply-to :references:x-mailer:mime-version:content-type :content-transfer-encoding:x-gm-message-state; bh=kQkRFi7jXlPhpwjth0o0SiYEOePLYUtYAhkyVu/QOyw=; b=M1ixtx+0+QiqiZHUFxcJunlaWubl5qwC95JyVkDLMmcn8mgOD9e6xkVNQZkX/tLTRv SeMotU4sBRjvNHivb2un74xaR4n73U6PMwyXkbZ2lYi85Tikq0nV8stH96VPW9dsC00R tZ1ADutfBTNjupmLnWjFVOIqeNRELDBoGmhAI8I6jv0KauTiKdBsHW9CbjlePBhQqQ7v jVnnL1p0Za+2Sglo0F5WzfS19RcnJJwLjuUuHHGCzJnYCVvyKrCsYgp3nRnN5eE9zLPV uDNn4Cz5WciXnsT1ItzysP99BhLOrDRxCE0qQzxWEvlpLD8FFCckKu359BLIYrs2nxgP q1YA== X-Received: by 10.180.93.74 with SMTP id cs10mr7642675wib.42.1370117919672; Sat, 01 Jun 2013 13:18:39 -0700 (PDT) X-ProxyUser-IP: 86.6.30.159 Date: Sat, 1 Jun 2013 21:18:36 +0100 From: Peter Stephenson To: "Zsh Hackers' List" Subject: Re: PATCH: configurability of pattern characters, part 1 Message-ID: <20130601211836.550bd8ac@pws-pc.ntlworld.com> In-Reply-To: <130531232223.ZM13592@torch.brasslantern.com> References: <20130601002954.0e30d7b9@pws-pc.ntlworld.com> <130531232223.ZM13592@torch.brasslantern.com> X-Mailer: Claws Mail 3.8.0 (GTK+ 2.24.7; x86_64-redhat-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Gm-Message-State: ALoCoQkgwxOLAzWV8V76/r/CLQyUvI1PLDu4u1fPKpUPw/sZEd44K7PAaArx0eWA3mjXtw5KyTw+ On Fri, 31 May 2013 23:22:23 -0700 Bart Schaefer wrote: > On Jun 1, 12:29am, Peter Stephenson wrote: > } > } The second step, to follow: now we have the "zpc_special" array, it will > } be possible (and fairly straightforward) to introduce a special variable > } to indicate pattern characters that should be turned off > > Possible alternative idea -- use the enable/disable builtins? > > disable -p '^' '(' '+(' That's quite reasonable, it makes it more natural to enforce particular entries than in an array. The simple meaning for enable -p is that it reverses a disable, it doesn't explicitly enable something that's not allowed by the options. I think I'll stick with that (though it needs clearly documenting). If you want to be able to enable or disable every pattern separetely, you "setopt extendedglob kshglob noshglob" first. > } We'll need to set the new shell variable(s) locally to empty for > } completion. > > Hmm, that's another problem with the enable/disable idea ... or is it? > "emulate -R zsh -c 'autoload _main_complete'" should do the trick ...? Yes, it should, but that's another story I haven't written yet, so we probably need another way... "disable -p" should output the current settings, which we could save. We reenable anything associated with extendedglob, turning off kshglob and shglob using the options as now, and use disable -p to redisable the user's stuff at the end in an "always" block. Or how about readonly zsh/parameter arrays corresponding to enabled and disabled patterns? Same idea, just slightly more efficient to save. (Could even be read/write; since they'd be documented as a front end to enable/disable rather than the basic syntax the scoping behaviour isn't so much of an issue.) > } I think also "emulate" should clear them (locally for "emulate -L") to > } present a pristine pattern environment for emulation. > > I agree ... which for me is an argument *against* using variables for > this. I know emulation modes already play with the special-ness of > things like HISTCHARS and MANPATH, but it doesn't actually go so far > as creating empty locals for them. The trouble is this creates an additional form of scope that's not options or parameters or traps for saving and restoring. However, there's nothing fundamentally difficult about that. Logically, to get emulate -L to behave as it does for options and traps, there should be an option "localpatterns" that causes the effects of disable -p to be restored after the current scope: otherwise we don't have a natural distinction between the behaviour of "emulate" and "emulate -L" (they'd have some hidden different effect on scoping, which I don't like). We just need to save one bit per pattern, so this is much more efficient than what we currently do for localoptions. In other words, "setopt localpatterns" would mean "restore the disabled pattern state at the end of the current function scope"; emulate's only contribution would be to set this if -L was given and in any case turn off the current disables. That's exactly parallel to localoptions except there's only one emulation state in this case, i.e. the one where the patterns are controlled only by the option settings. > Speaking of HISTCHARS, do we agree that it'd be a bad idea to be able > to swap around which characters have what glob semantics? E.g., it's > OK if * means only "*", but you can't make % mean "match any number of > any character". Yes, I really don't think there's any sense in allowing this. It causes confusion far beyond any convenience it produces. -- Peter Stephenson Web page now at http://homepage.ntlworld.com/p.w.stephenson/