From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20195 invoked from network); 28 May 2009 09:25:38 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.5 (2008-06-10) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.2.5 Received: from new-brage.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.254.104) by ns1.primenet.com.au with SMTP; 28 May 2009 09:25:38 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 25528 invoked from network); 28 May 2009 09:25:33 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 28 May 2009 09:25:33 -0000 Received: (qmail 26032 invoked by alias); 28 May 2009 09:25:26 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 27009 Received: (qmail 26016 invoked from network); 28 May 2009 09:25:26 -0000 Received: from bifrost.dotsrc.org (130.225.254.106) by sunsite.dk with SMTP; 28 May 2009 09:25:26 -0000 Received: from smtprelay10.ispgateway.de (smtprelay10.ispgateway.de [80.67.29.24]) by bifrost.dotsrc.org (Postfix) with ESMTP id 73866801E289 for ; Thu, 28 May 2009 11:25:22 +0200 (CEST) Received: from [212.117.84.96] (helo=fsst.voodoo.lan) by smtprelay10.ispgateway.de with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.68) (envelope-from ) id 1M9brU-0008Dz-Do for zsh-workers@sunsite.dk; Thu, 28 May 2009 11:25:21 +0200 Received: from hawk by fsst.voodoo.lan with local (Exim 4.69) (envelope-from ) id 1M9brO-0005JG-LP for zsh-workers@sunsite.dk; Thu, 28 May 2009 11:25:14 +0200 Date: Thu, 28 May 2009 11:25:14 +0200 From: Frank Terbeck To: zsh-workers@sunsite.dk Subject: Re: PATCH: Add CORRECT_NOCOMPSYS option Message-ID: <20090528092514.GA3315@fsst.voodoo.lan> Mail-Followup-To: zsh-workers@sunsite.dk References: <1238890030-4683-1-git-send-email-ft@bewatermyfriend.org> <090404193718.ZM19801@torch.brasslantern.com> <20090405191304.1908fca8@pws-pc> <090405151115.ZM13159@torch.brasslantern.com> <20090406100929.505617e2@news01> <2d460de70905270930j681da6a5kf7848d67d89f0c69@mail.gmail.com> <20090527175941.3bbe2eba@news01> <2d460de70905280148iebfcegcb4143c33e510efd@mail.gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline In-Reply-To: <2d460de70905280148iebfcegcb4143c33e510efd@mail.gmail.com> User-Agent: Mutt/1.5.18 (2008-05-17) X-Df-Sender: 430444 X-Virus-Scanned: ClamAV 0.94.2/9398/Thu May 28 05:01:33 2009 on bifrost X-Virus-Status: Clean Richard Hartmann : > On Wed, May 27, 2009 at 21:12, Greg Klanderman wrote: > > > But in the same vein, what I really want is a way to configure the > > behavior for functions, variables, etc. beginning with "_" to be like > > filenames beginning with ".": completion should work if I have > > explicitly typed the leading "_", but even substring matching should > > not *generate* a leading "_". > > I think this is a good explanation of what, imo, the final goal should > be. The final goal for what? For completion (without looking at it in detail), I think what Greg wants could be done with the _ignore completer. At least I got something similar for a set of commands: zstyle ':completion:*:complete:-command-::commands' \ ignored-patterns 'aptitude-*' Because I never want to complete the commands named aptitude-create-state-bundle or aptitude-run-state-bundle. With the above style 'apti' always completes to 'aptitude'. But 'aptitude-' offers the two commands mentioned earlier, too, in case I really really want one of them. My completer style looks like this: zstyle ':completion:*' completer _expand _complete _ignored _approximate Where _ignore is the important bit. That's completion. Correction is a whole other deal. And CORRECT_IGNORE is just for that. So you don't get completion functions as _suggestions_ for _correction_. (E.g. you don't have vim installed but you try to execute it, chances are that correction will ask you 'zsh: correct 'vim' to '_vim'? (YNEA)' - which is utterly useless and annoying). So, when you're talking about a final goal, IMHO, CORRECT_IGNORE is quite a reasonable solution. And it *only* works on words in command position (aka. the stuff 'setopt correct' does - words corrected by 'setopt correct_all' are not touched at all). Regards, Frank -- In protocol design, perfection has been reached not when there is nothing left to add, but when there is nothing left to take away. -- RFC 1925