From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2811 invoked from network); 14 Aug 2001 12:25:56 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Aug 2001 12:25:56 -0000 Received: (qmail 18049 invoked by alias); 14 Aug 2001 12:25:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15624 Received: (qmail 18037 invoked from network); 14 Aug 2001 12:25:46 -0000 From: martin.ebourne@arcordia.com Subject: Re: PATCH: Re: Delaying menu completion To: Sven Wischnowsky Cc: zsh-workers@sunsite.dk Date: Tue, 14 Aug 2001 13:24:33 +0100 Message-ID: X-MIMETrack: Serialize by Router on LON-ARCMTA-01/ARCORDIA(Release 5.0.3 (Intl)|21 March 2000) at 08/14/2001 01:24:35 PM MIME-Version: 1.0 Content-type: text/plain; charset=us-ascii > So I'd have changed it to either: > > if zstyle -t "..." insert-unambiguous; then > compstate[pattern_insert]=unambiguous > elif _requested ... > > or > > zstyle -s "..." insert-unambiguous ins > if [[ $ins = (true|yes|on|1) || > ( $ins = sometimes && > $compstate[unambiguous] -is sensible ) ]]; then > compstate[pattern_insert]=unambiguous > elif _requested ... > > What do people think? Should we make `always' normal the meaning of > insert-unambiguous==true? Keep the test? Making it be used on a new > special value would of course do no harm. The problem here is this will give you what I had been getting yesterday when playing with this. In the case that the unambiguous bit is shorter than the word on the command line, the extraneous stuff is deleted from the command line. This certainly isn't what I wanted (maybe someone does though) - I just wanted it to do nothing at all, leaving me to either edit the line or invoke menu selection. In order to get that to happen, the following chunk of code I purloined from _match is essential: [[ "$compstate[insert]" != *menu ]] && compstate[pattern_insert]= compstate[insert]= > Ah. Humm. That's caused by completecall() (in zle_tricky.c). The > problem is that the completion widgets normally return non-zero if no > matches were generated and the code there tries to ensure that even > for user defined completion widgets. I.e., it specifically replaces > the zero returned from a user-defined widget with a `1' to signal that > completion `failed'. That's ugly in cases like this one, yes, but I > don't know if we should change it. Sounds like something that's better left alone to me. Presumably the returning 1 is to get zsh to ring the bell. Perhaps a note on this in the info pages would be the best solution. Cheers, Martin.