Re: collist (and hooks)

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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@xxxxxxxxxxxxxxxxxxxxxxx