From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2476 invoked from network); 21 Jun 1999 13:17:38 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 21 Jun 1999 13:17:38 -0000 Received: (qmail 22994 invoked by alias); 21 Jun 1999 13:17:10 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 6764 Received: (qmail 22987 invoked from network); 21 Jun 1999 13:17:08 -0000 Date: Mon, 21 Jun 1999 15:17:05 +0200 (MET DST) Message-Id: <199906211317.PAA23092@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: Peter Stephenson's message of Mon, 21 Jun 1999 14:21:20 +0200 Subject: Re: collist (and hooks) Peter Stephenson wrote: > Some comments: > - It's hard to get out of at the moment. Unrecognized keys should probably > turn it off, particularly self insert, in much the same way they do with > ordinary menu completion. You should also be able to deactivate it > leaving nothing inserted but without aborting everything. That ought > to satisfy many of the ordinary-menu-completion-phobes. Yes. And these other keys should then be fed into the getkeycmd()-loop again to have immediate effect. I thought about this but then... I only wanted to play a bit (this comment also applies to the other comments). > - When it does get deactivated, the chosen item should be unhighlighted > immediately as a piece of visual feedback. > - (This is pretty much the same thing): I actually find it annoying that > the current menucompletion item is highlighted even when menu-select > is not active. I think at least there should be a separate code for > the two (and I'd suggest the default for the ordinary menu completion one > wasn't so highly visible). I did that for normal menucompletion only to try it before implementing menu-select (and there were some hours of real work between the two). I agree that it's not really needed for menucompletion. And then we don't need to use the do_single()-hook. > - It would be quite nice to have some way of getting into it automatically, > I suppose either by compconfig or by a completer. To get this to work > naturally, it's particularly important to have the visual feedback for > menu-select on/off, as a signal that the cursor keys and a few others are > special. Then any other key could deactivate it and have its usual effect. See above (;-) and: question is if we want those compctl-folks to be able to use it automatically. If so we would (obviously) need a different approch -- one I can't think of at the moment. But we could add a hook that is called when the completion code turns on auto-menu. Then the collist module could decide what is to be used. Hm. Is it time to add module-defined options? > - Something a bit grotesque is happening when the completions don't all fit > on the screen. Maybe it shouldn't even work in that case (certainly not > automatically). It certainly shouldn't override `do you wish to see all > 2811 possibilities' as it does at present. Err. Have you applied 6753? (And the one below, which is the reply to 6762. Ahem.) > - I suppose a long term aim would be to have special keymaps for the > minibuffer and this, too. But there's no hurry for that. Definitely, yes. > - Probably not only this needs documenting, but the codes for ZLS_COLOURS in > more detail; I don't think we can rely on using GNU ls manual. But then > we'll have to write it from scratch. Yes, of course. I was just too lazy, not knowing if anybody likes it at all. About the colour-codes: is there a manual-patch from Greg (should be almost the same). Another thing we should try to achieve is that the refresh code does not clear to EOD every time the list is redisplayed. And we should probably make compinit and friends be aware of menu-select. And another thing I forgot to mention: how about adding more hooks in interesting places so that modules can make themselves be called? (Not only in the completion code: parameter access, the places where we currently have special shell functions, mail-checks, ... Any suggestions? They are easy to add and the tests can be made quite fast.) Bye Sven diff -u os/Zle/collist.c Src/Zle/collist.c --- os/Zle/collist.c Mon Jun 21 12:49:47 1999 +++ Src/Zle/collist.c Mon Jun 21 15:07:43 1999 @@ -390,7 +390,7 @@ tcmultout(TCUP, TCMULTUP, nlnct); } else putc('\n', shout); - return 0; + return; } if (clearflag) { putc('\r', shout); -- Sven Wischnowsky wischnow@informatik.hu-berlin.de