From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from euclid.skiles.gatech.edu (euclid.skiles.gatech.edu [130.207.146.50]) by werple.net.au (8.7/8.7.1) with ESMTP id SAA19801 for ; Fri, 8 Dec 1995 18:40:32 +1100 (EST) Received: (from list@localhost) by euclid.skiles.gatech.edu (8.7.3/8.7.3) id CAA27901; Fri, 8 Dec 1995 02:20:24 -0500 (EST) Resent-Date: Fri, 8 Dec 1995 02:20:24 -0500 (EST) Date: Fri, 8 Dec 1995 08:20:31 +0100 (MET) From: wischnow@informatik.hu-berlin.de (Sven Wischnowsky) Message-Id: <199512080720.IAA18489@beta.informatik.hu-berlin.de> To: zsh-workers@math.gatech.edu In-reply-to: Richard Coleman's message of Thu, 07 Dec 1995 15:22:42 -0500 Subject: Re: couple of zsh features Resent-Message-ID: <"lTn4p1.0.qp6.tS-nm"@euclid> Resent-From: zsh-workers@math.gatech.edu X-Mailing-List: archive/latest/682 X-Loop: zsh-workers@math.gatech.edu Precedence: list Resent-Sender: zsh-workers-request@math.gatech.edu Richard Coleman wrote: > > > I do think correctall would be more usable if you could actually enter > > the corrected spelling at the SPROMT, rather than merely accepting or > > rejecting the guess and then having to go back to zle to edit the line. > > > > } Maybe some kind of compctl-based matching could be used to determine > > } which word in the previous command was a likely mismatch. > > > > It might be useful to have the word or character position of the last > > failed correction available to compctl, and to have a history reference > > for the last unknown command or syntax error. > > I've also been thinking about similar things. A lot of the recent > work in zsh has moved more of the intelligence in the code into > the hashtable code. To use an overused buzz-word, the internals > of zsh have become more `object-oriented' in some sense. This is > a trend I would like to continue. The next thing would be to move > some of the command completion and spelling correction code into > hashtable.c. So (in some sense) each type of object (alias, builtin, > etc...) would know how to complete itself, or spell check itself. > Once this is done, I think we could generalize the code so that both > spelling correction and command completion would be programmable > in similar ways. > > Just a thought. > Oh yes. I thought about that a lot when I was working on zle_tricky. It would be nice to turn that completion code into a general `produce a list of what we need here'-code. The main problem (I think) is that we would need a good internal representation for lexed (and parsed) command lines that would be used throughout the whole code. Once we had this, it wouldn't be too complicated to turn the completion code (and merge it with the correction code) into the above mentioned list-generator (we probably would also have to add some more possibilities for describing command arguments). Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de