From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10702 invoked from network); 11 Feb 2002 16:38:39 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 11 Feb 2002 16:38:39 -0000 Received: (qmail 15950 invoked by alias); 11 Feb 2002 16:38:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16602 Received: (qmail 15938 invoked from network); 11 Feb 2002 16:38:31 -0000 Date: Mon, 11 Feb 2002 11:38:28 -0500 From: Clint Adams To: Oliver Kiddle Cc: zsh-workers@sunsite.dk Subject: Re: correction hook Message-ID: <20020211163828.GA17897@dman.com> References: <20020211080823.GA9961@dman.com> <20020211130457.70106.qmail@web9307.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020211130457.70106.qmail@web9307.mail.yahoo.com> User-Agent: Mutt/1.3.27i > Aliases have served me well for the few common typos like this. I have > reservations about this because this simple function probably doesn't > go far enough. How might you disable correction for certain words, e.g. > the destination to a mv command? Sorry, I described a specific case and forgot to mention the more general problems. They are as follows. 1) In the case of mak/mawk/make, the user has no instances of 'mawk' in his history, but he has recently typed 'make'. The correction algorithm is unaware of these details. 2) When one has CORRECT_ALL set, correction isn't nearly as intelligent as completion. I have things like alias cp='nocorrect cp' alias mkdir='nocorrect mkdir' alias mv='nocorrect mv' Rather than adding a slew of additional aliases, it would be nice if correction were smart enough not to assume that arguments to, f.ex., ssh should match local files. > I'm not entirely convinced by the correction mechanism because it has > to interrupt you with its prompt. With the new completion system I get > any typo in a word I completed corrected by _approximate anyway. I'd be > more inclined to think about a totally different way of spotting and > communicating typos such as using the completion system continually and > underlining possible typos. I imagine that would be slow, though quite useful to some.