From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11060 invoked from network); 7 Apr 2002 16:51:40 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 7 Apr 2002 16:51:40 -0000 Received: (qmail 23694 invoked by alias); 7 Apr 2002 16:51:32 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16941 Received: (qmail 23681 invoked from network); 7 Apr 2002 16:51:31 -0000 Message-ID: <20020407165129.54854.qmail@web10402.mail.yahoo.com> Date: Sun, 7 Apr 2002 09:51:29 -0700 (PDT) From: Felix Rosencrantz Subject: Re: correction hook To: zsh-workers MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii This is a response to an old thread from February. A draft I wrote in March. The topic hasn't come up in a while, so it seems like there wasn't much interest. -FR On Mon, 11 Feb 2002 Bart Schaefer wrote: >On Mon, 11 Feb 2002, Clint Adams wrote: >> 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. > >"Past performance is no guarantee of future results." Just because a >software developer tends to type "make" repeatedly, doesn't mean that's a >good indication of the behavior of some other shell user. Correction is never going to be 100% right. The idea is to improve the odds. Different scoring strategies (e.g. commands previously used score higher) will give different results that will depend on the user&tasks at hand. I think it would be useful, if just like completion, correction could use different scoring strategies for performing correction. So many times I find I'm upset with correction for offering up commands I have never used. So this would be one strategy for finding a good correction. But a different user may find that this is not for them. Maybe that user is very prone to having one of their hands offset on the keyboard (more becomes nire), so that user might prefer to use a keyboard hand offset strategy. >> 2) When one has CORRECT_ALL set, correction isn't nearly as intelligent >> as completion. [...] >> Rather than adding a slew of additional aliases, it would be nice if >> correction were smart enough [...] > >We've discussed before that the correction system could be tied to >completion. It'd have to be something equivalent to that in order for it >to "know" the legitimate arguments to every possible command, and there's >no point in inventing all of that twice. Sounds like time to plug the XML completion stuff... :) It would be easy to take the XML description of a command and convert that into a getopt like description, which could be used to parse the command line. And the XML description could still be used to generate a completion function. If there is no checker for a command, it just scores lower than other commands, assumption that this command is not interesting to the user. >Correction could actually go one step further -- when it finds a command >name it wants to correct, it could, for each possible correction, attempt >to check the argument list against the possible completions, and pick the >correction for which the existing arguments give the best match. (That >would be some impressive code. Anybody looking for a Master's thesis >project?) Seems like you have described a good algorithm. Not sure why it would have to be as complicated as a Master's thesis. With some sort of getopt-parsing, and argument count checks, it might be a useful strategy for correcting a command. (Though with a good hook mechanism in place, it would make it easier for someone to tackle this as a Master's thesis project.) I've always been pretty impressed with the results of predictive-type widget you've written. It works really well in certain circumstances. All just by calling completion. Though shell typing prediction has been the subject of a few graduate students research. (I mention the ones I know in zsh-workers/12289.) So it might be possible to use some less complicated algorithms and still get good results. Also, it might be useful if there were a few more options at the correction prompt. What if zsh offered more that one possible correction (rather than the "I'm feeling lucky" way). The user could select the best choice via a number menu, or completion menu. Maybe we should allow the user to jump directly into completion from the correction message. On Mon, 11 Feb 2002 Oliver Kiddle wrote: >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 like that idea. That would be very useful. Though, if the user didn't fix the command name, the shell should still prompt about the problem. So there would still be the issue of post-enter command line correction. Also, there is a difference between correction and approximation. Command correction uses a scoring system that not only counts errors, it also looks at which errors are more likely based on a model of the keyboard. (At least that what I remember...) Which is different than the _correct completer... I would like to see some improvements on the correction front. I think a hook would be useful. And potentially could provide even better correction choices. Also, if we had some way of highlighting problems as the user typed, that would be useful. My experience with tcsh and zsh, is that zsh does a much better job at correction than tcsh did. (It's been a while since I used tcsh.) I believe the reason was related to the fact that zsh used a scoring system that modeled the keyboard, while tcsh just did a score based on typing error counts. Throw in past command usage, some flag&argument checking, multiple choices, and some completion correction could be even better. -FR. __________________________________________________ Do You Yahoo!? Yahoo! Tax Center - online filing with TurboTax http://taxes.yahoo.com/