From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12523 invoked from network); 28 Jun 2000 08:12:05 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 28 Jun 2000 08:12:05 -0000 Received: (qmail 14060 invoked by alias); 28 Jun 2000 08:11:59 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12095 Received: (qmail 14053 invoked from network); 28 Jun 2000 08:11:59 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer david.siemens.de) From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: PATCH: Re: undo in menu selection broken Date: Wed, 28 Jun 2000 12:11:56 +0400 Message-ID: <000401bfe0d8$86800d80$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0) In-Reply-To: <200006280728.JAA31591@beta.informatik.hu-berlin.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > > The patch should also fix the undoing behaviour (Andrej, in your > example you had typed `.', `/' and then TAB, right? guess what...). > Yes. > > What this patch does *not* do is fix the behaviour of a-a-i-n-h when > there is no match. I was thinking about making it just show some > message and let undo bring you back. Or maybe let it stay in the > selection it currently is in and show some message. But: > I think, this is more general problem. I do not like what currently happens, when no match is found. 1. There is hardly any visual feedback (well, with verbose style and group names you get sort of). Good ole compctl had an option to display a message in this case ... I do not recall something like this in new completion system. Is there any style I can set to simply display "No matches found" in this case? 2. Something very funny happens if there is no matches and you hit TAB several times. The worst is, that line is erased. This hapens in menu selection and in normal completion as well. Consider: bor@itsrm2% cd Completion/TAB bor@itsrm2% cd Completion/AIX/ Completing local directories AIX/ Bsd/ CVS/ Core/ Linux/ X/ Base/ Builtins/ Commands/ Debian/ User/ AIX is selected; after `/' bor@itsrm2% cd Completion/AIX/CVS/ Completing local directories CVS/ after `/' bor@itsrm2% cd Completion/AIX/CVS/ Completing local directories CVS/ `/' once again bor@itsrm2% cd / Completing `local directories' or `directories in cdpath' Oops! This is the case of menu selection, but the same happens in normal (non-menu) completion as well. The last output is the example of "sort of feedback" - you can see, that no matches were found. But what I do not expect, that line is erased. > 1) I wouldn't like to hard-wire this message, but adding a parameter > just for this looks kinda weird. > Or maybe just add a ZLS_COLOURS capability for it. See above. Style for general use is really welcome (not only for this one widget) > 2) Setting the format style for the warnings tag to a value without a > `%d' makes it add the descriptions of the things it tried as > matches which gives a much better output than using `%d'. But with > this, there's never a completion without matches and a-a-i-n-h > happily starts completing the descriptions. So maybe a-a-i-n-h > in menu-selection should set some parameter so that the shell code > can find that out. Even better would be to change the complete > module so that other modules like complist can put things into > $compstate. > Ahem ... sorry, but I simply do not understand it :-)) I'm speaking from a user's point if view ... -andrej