From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10455 invoked from network); 27 Apr 1999 11:06:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 27 Apr 1999 11:06:38 -0000 Received: (qmail 3238 invoked by alias); 27 Apr 1999 11:06:22 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6119 Received: (qmail 3231 invoked from network); 27 Apr 1999 11:06:21 -0000 Date: Tue, 27 Apr 1999 13:06:10 +0200 (MET DST) Message-Id: <199904271106.NAA11416@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Tue, 27 Apr 1999 11:59:14 +0200 Subject: Re: PATCH: was Re: Closing quotes in completion Peter Stephenson wrote: > That seems to fix the problem I was worried about. One difficulty is you > get a (removable) space between the end of the completion and the quote > (where the cursor ends up) when there's a unique match. That's not so bad, > but it is it really correct deliberately to insert a space *before* a > suffix? Err, right. Since the space is considered to be the automatically inserted separator for the next word and is not a part of the completed string, we shouldn't insert it before the ISUFFIX. > (There's also the old problems with completing in quotes where you > expect "filename wi to complete to "filename with spaces", but if I > remember right that's made difficult by the lexer.) Which it does. The problem is that you don't get the backslashes if you want them even inside quotes (`zsh -c "ls f'). And there is no way how the completion code could detect what you want. > > This also reminds me of the last thing I'm still thinking about for > > the new style completion stuff: a way to access and probably modify > > the completions added. > > > > Because of these problems I haven't implemented anything of this yet, > > so I'd like to hear comments/suggestions about all this. > > The only thing that strikes me is the idea of having a fairly raw access to > the structures, i.e. if you really know what you're doing there's some > option for you to modify pretty much anything. But I don't know either the > uses for or the difficulties with that. The only uses I can think of are: - Getting information about an old list or about a new list after all completions have been added to find out what to insert. Some time ago, we had some people here asking if it would be possible to give different compctl-flag-lists for a command and then have the completion code first insert only matches from the first list, then invoke some other widget to skip over to the next list and so on. If at all I would like to do such things with groups of matches. In fact, this is the reason why I made inserting the n'th match from the m'th group so easy with the compstate[insert] key. For that it would be nice to be able to get information at least about the different groups (name, how many matches, etc.). - compadd allows more detailed control over some of the things then compgen (the is-a-file-flag, the remove-characters/function). Being able to set these fields in matches from compgen is currently the only thing I can think of where modifying the generated list of matches might be useful. And have to do this by hand is ugly, of course, options for compgen to give control over this would be much better. But we have only one more option-letter (plus some non-alphabetic characters) free for comp{ctl,gen}: `h'. Now, if we had support for long-options... Bye Sven diff -u os/Zle/zle_tricky.c Src/Zle/zle_tricky.c --- os/Zle/zle_tricky.c Tue Apr 27 11:03:35 1999 +++ Src/Zle/zle_tricky.c Tue Apr 27 12:45:30 1999 @@ -7049,7 +7049,6 @@ /* If we didn't add a suffix, add a space, unless we are * * doing menu completion or we are completing files and * * the string doesn't name an existing file. */ - cs = scs; inststrlen(" ", 1, 1); menuinsc++; if (menuwe) -- Sven Wischnowsky wischnow@informatik.hu-berlin.de