From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4020 invoked from network); 16 Aug 2001 10:57:29 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Aug 2001 10:57:29 -0000 Received: (qmail 22628 invoked by alias); 16 Aug 2001 10:57:23 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15643 Received: (qmail 22616 invoked from network); 16 Aug 2001 10:57:23 -0000 From: Sven Wischnowsky Message-ID: <15227.42756.700159.266050@gargle.gargle.HOWL> Date: Thu, 16 Aug 2001 12:57:08 +0200 MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: zsh-workers@sunsite.dk Subject: Re: all-matches with a suffix In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 3) "Acadia" XEmacs Lucid martin.ebourne@arcordia.com wrote: > > 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? Eh? It puts all matches into the command line without re-displaying it after every match -- only redisplaying it at the end. > ... > > 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. Yes, but that's not the real problem. There are many different styles of how suffixes and all-matches should be handled (and that also affects how prefixes are to be handled, as in your conv=value example). I don't want to have yet another case of adding a bit and then some more and some more and... What I really want is to move more of the completion setup and finalisation code into shell code, to make it more flexible and to allow more people to play with it. Then I'd even like to remove some of the options to compadd (-q, -r, -R -- especially -R). That means identifying stuff for which we need C-code support and adding builtins and/or special parameters for that. Then we can hopefully remove the suffix handling from the zle module, and probably even get rid of the difference between normal and completion widgets. For things like auto-removable suffixes zle would offer a hook or something equally generic (some kind of {pre,post}-command-hook). The rest would be in shell code with a function to register prefixes and suffixes and to say how they should be handled in different situations. Or something like that. I haven't thought that much about all this yet, because I don't have much time now. We had some discussion about suffix handling some time ago (last year, I think), but I'd have to search for it in the archive, too, because somehow it fell from my todo list. Ahem. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de