From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2584 invoked from network); 14 Aug 2001 12:02:24 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 14 Aug 2001 12:02:24 -0000 Received: (qmail 13951 invoked by alias); 14 Aug 2001 12:02:17 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 15622 Received: (qmail 13933 invoked from network); 14 Aug 2001 12:02:16 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15225.4924.267164.433795@gargle.gargle.HOWL> Date: Tue, 14 Aug 2001 14:02:04 +0200 To: zsh-workers@sunsite.dk CC: martin.ebourne@arcordia.com Subject: PATCH: Re: Delaying menu completion In-Reply-To: References: X-Mailer: VM 6.92 under 21.1 (patch 3) "Acadia" XEmacs Lucid martin.ebourne@arcordia.com wrote: > ... > > > The caveat I mentioned is that _approximate has this strange test in it: > > [[ "${#compstate[unambiguous]}" -ge "${#:-$PREFIX$SUFFIX}" ]] > > That means that the unambiguous prefix must be longer than the word on > > the command line. I.e., there's no way to prevent it dropping into > > menu completion unless all the matches have a common prefix longer than > > what's on the line right now. I don't remember what that was supposed > > to accomplish, but it seems a rather unlikely situation. Sven? We had some discussion about this twice, I think. My hope was that it would use normal (non-menu) completion only if there was some sensible unambiguous prefix. That, based somehow on the original string. I think I mentioned that I wasn't sure about this even when I first wrote it... noone came up with anything better. > I had previously discovered this and tried removing that condition but it > still didn't work properly. However, armed with the now working match above > I've managed to get it to do what I want. With the patch below, I can set > insert-unambiguous to 'always' and then it never enters menu completion, > which is exactly what I'm after. > > Someone will need to check the patch because I don't fully understand > what's going on - its a combination of cut & paste and trial & error coding > in there. ;) I was thinking about the same yesterday. I just wasn't sure if we shouldn't remove that test completely, or make a `true' value keep it always from starting menu completion and add some other value for a -- probably improved -- test to use normal completion when there is a sensible unambiguous string. 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. > ... > > But 'zle is-completing' wasn't giving the return code (although the info > pages say it will). 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. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de