From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3813 invoked from network); 16 Aug 2001 10:30:25 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Aug 2001 10:30:25 -0000 Received: (qmail 18212 invoked by alias); 16 Aug 2001 10:30:18 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15642 Received: (qmail 18197 invoked from network); 16 Aug 2001 10:30:17 -0000 From: martin.ebourne@arcordia.com Subject: Re: all-matches with a suffix To: zsh-workers@sunsite.dk Date: Thu, 16 Aug 2001 11:28:11 +0100 Message-ID: X-MIMETrack: Serialize by Router on LON-ARCMTA-01/ARCORDIA(Release 5.0.3 (Intl)|21 March 2000) at 08/16/2001 11:28:15 AM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii > The problem here is that it has to cheat if you want to call it that. > There is this pseudo match I've been talking about already, containing > all the other matches. In order to insert that match, it inserts the > other matches one by one, as if one were in a menu completion and > repeatedly using accept-and-menu-complete, typing spaces between the > matches. I'm not surprised - it certainly looks like that's what its doing since the line visibly 'grows' as it is entered. Is it not possible to build up the full match and add it in one go? > Now the `-r' option means that the suffix (-S ', ') should > be removed if the next character typed is a space (or a comma, or...). > That auto-remove thing is certainly the right thing when used > interactively, but for this all-matches thing... > > Hm, we had some discussion about all this suffix handling anyway, so > maybe we should start collection other problems people see or have > seen with it and then find the real solution. At least I can't see > any simple solution now, without adding another option to compadd, > telling it how it should behave for a-a-m-c. and that would look like > a hack, somehow. Well the option may not be such a bad idea. I can think of occasions where you would want a space separating the results, and others where you wouldn't. It's not obvious how the completion code could otherwise decide. Four cases I've though of so far are: 1. Expanding all matches on a list of directories, you would probably want the trailing '/' removed, and the results separated by spaces. This is what it does currently. 2. Expanding the SQL selection list you would want the separator ', ' used as is (though an extra space wouldn't hurt). Currently the line ends up being corrupted. 3. Expanding 'dd conv=*' you would want the separator ',' used as is, and an extra space would be a problem. (eg. 'dd conv=ascii,lcase,') Currently it expands to a list of 'conv=value ', which I guess is ok, but it's probably not what I'd expect. Also it may depend on the command if that is valid. 4. Expanding 'dd *' you would want the separator '=' used with a space appended. This is what it does currently. In addition, for case (2), if I had select table.* from table and expanded after '*', I'd want select table.col1, table.col2, table.col3, from table which is a lot like (3) currently behaves (though currently the line still gets corrupted due to the ', ' suffix removal.) Finally, a separate note about 3, is that if I enter: dd conv=a and complete, I get dd conf=ascii, which would be fine. But then instead of offering more completions for the list when I try completion again, it tries to correct the word to 'ascii' (1 error). It doesn't succeed though. Cheers, Martin.