RE: completion widgets in menu selection

RE: completion widgets in menu selection

[Sven Wischnowsky]

I wrote:

> ...
> 
> I'd also like to point out to Jay (although he probably found that out 
> already), that all this doesn't really have anything to do with menu
> completion, i.e. it works just fine without that. The discussion about 
> menu *selection* we had was about making such extra special key
> bindings work from withing that (and it's the patch for that which has
> been added).

Before someone corrects me... of course there is a bit of interaction
with menu completion or selection. Without that you won't be able to
select that all-matches-match.

For people who don't really like menu completion but sometimes envy
people that use it, there is the automenu option (and the menu
style). Using menu selection instead of ol' menu completion should
make navigation easier.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: completion widgets in menu selection

[Andrej Borsenkow]

>
> Before someone corrects me... of course there is a bit of interaction
> with menu completion or selection. Without that you won't be able to
> select that all-matches-match.
>

This is one more reason why I prefer separate widget solution.

I am curious if anybody will really use _all_matches as part of regular
default completion.

> For people who don't really like menu completion but sometimes envy
> people that use it, there is the automenu option (and the menu
> style). Using menu selection instead of ol' menu completion should
> make navigation easier.
>

Yes, menu selection seems to have spoiled zsh-workers. Should I dig out
not-so-old articles about list vs. menu signed "Sven"? :-))

-andrej

RE: completion widgets in menu selection

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> > In the last several weeks, I raised three issues on this list:
> >
> >  1. a|TAB being broken (which was fixed and I assume committed to
> >     CVS)
> >
> >  2. being able to more flexibly say that the completion rules for one
> >     command should be identical to another (as in _rlogin) without
> >     requiring Draconian restrictions on how completion functions
> >     should be organized
> >
> >  3. (my favorite) being able to insert all completions that match the
> >     current shell globbing expression into the commandline.
> >
> > The first issue is obviously resolved.  The second issue has generated
> > less traffic than the third and I haven't had much trouble following.
> > It seems like a good track is being followed.
> >
> > On the final issue, I'm confused about where things are going.  I've
> > decided that, as Bart suspected all along, I don't really like TAB
> > automatically "expanding" my glob expression even in the case of cvs
> > add.  What I think I really like is the _insert_all_matches option.
> > That way I can hit TAB to see what would complete without actually
> > having the completion be done, and if I'm satisfied, do something like
> > ^Xi to do the expansion.  Has this functionality actually been added,
> > or was it just discussed?
> 
> Hey ho! Now I'm not alone! :-)))
> 
> Yes, all prerequisites are  implemented in current CVS. What is missing, is
> the widget/key binding itself, but if you use example from docs verbatim, it
> works. I've tried it and I confirm it.
> 
> If you have suggestions what this _insert_all_matches should do - you are
> welcome. The difference between example and my version is that in my version
> you could hit ^Xi - and if there was no list, it called normal completion. Is
> this interesting? Example from docs will work only after existing list has
> already been generated.

But of course it's easy to do, just change the example to use:

  zstyle ':completion:all-matches:*' completer _all_matches _complete

(Or _match instead of _complete for the pattern-matching behaviour.)


I'd also like to point out to Jay (although he probably found that out 
already), that all this doesn't really have anything to do with menu
completion, i.e. it works just fine without that. The discussion about 
menu *selection* we had was about making such extra special key
bindings work from withing that (and it's the patch for that which has
been added).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

completion widgets in menu selection

[Sven Wischnowsky]

[The last uncommitted patch.]

As promised, here is the patch that makes completion widgets that are
not directly handled by the menu selection code leave menu selection
without accepting the match currently selected.

Together with the _all_matches stuff, this allows one to use a
key-binding that inserts all matches from within menu selection
without having to fiddle with key bindings.

The more I think about this, the more sense does it seem to make,
especially because this allows everything that was possible before
plus some.

Bye
 Sven

diff -u -r ../oz/Src/Zle/complist.c ./Src/Zle/complist.c
--- ../oz/Src/Zle/complist.c	Tue Oct 10 21:38:58 2000
+++ ./Src/Zle/complist.c	Tue Oct 10 21:55:20 2000
@@ -2237,7 +2237,11 @@
 	    continue;
 	} else {
 	    ungetkeycmd();
-	    acc = 1;
+	    if (cmd->widget && (cmd->widget->flags & WIDGET_NCOMP)) {
+		acc = 0;
+		broken = 1;
+	    } else
+		acc = 1;
 	    break;
 	}
 	do_single(**p);
@@ -2260,6 +2264,7 @@
 	menucmp = 2;
 	showinglist = -2;
 	minfo.asked = 0;
+	zrefresh();
     }
     if (!noselect && (!dat || acc)) {
 	showinglist = -2;

--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

RE: completion widgets in menu selection

[Andrej Borsenkow]

>
> As promised, here is the patch that makes completion widgets that are
> not directly handled by the menu selection code leave menu selection
> without accepting the match currently selected.
>

Excellent! I am espicially impressed by the size of patch :-)

> Together with the _all_matches stuff, this allows one to use a
> key-binding that inserts all matches from within menu selection
> without having to fiddle with key bindings.
>

I even suggest, that this be included in distribution.

> The more I think about this, the more sense does it seem to make,
> especially because this allows everything that was possible before
> plus some.
>

One problem. How should undo after this second widget behave? Curretly it
leaves the last match, selected in menu selection, inserted and forgets about
list. It would be very nice if it returned to menu selection ... but I do not
know how difficult it is.

More general. With amount of state information kept in compstate it is very
easy to write separate bindable commands that modify generated lists. It would
be very nice if undo returned to previous state in this case.

-andrej

Re: completion widgets in menu selection

[E. Jay Berkenbilt]

[This message is primarily directed at Sven, Andrej, and Bart.]

I keep hoping I'm going to have time to really study the 58 messages
in my zsh inbox but I don't know when that's going to happen, so I'm
breaking down and sending this message.

In the last several weeks, I raised three issues on this list:

 1. a|TAB being broken (which was fixed and I assume committed to
    CVS)

 2. being able to more flexibly say that the completion rules for one
    command should be identical to another (as in _rlogin) without
    requiring Draconian restrictions on how completion functions
    should be organized

 3. (my favorite) being able to insert all completions that match the
    current shell globbing expression into the commandline.

The first issue is obviously resolved.  The second issue has generated
less traffic than the third and I haven't had much trouble following.
It seems like a good track is being followed.

On the final issue, I'm confused about where things are going.  I've
decided that, as Bart suspected all along, I don't really like TAB
automatically "expanding" my glob expression even in the case of cvs
add.  What I think I really like is the _insert_all_matches option.
That way I can hit TAB to see what would complete without actually
having the completion be done, and if I'm satisfied, do something like
^Xi to do the expansion.  Has this functionality actually been added,
or was it just discussed?

More recently, there's been a discussion of adding some ability in
menu completion to have one option that inserts all matches.  This
seems quite compelling, but what about those of us who don't use menu
completion?  Maybe I should try menu completion for a while.  I may
end up liking it.  The main thing is (and this is why I've reversed my
position on TAB automatically expanding for non-unique match
situations) I really don't like my commandline changed when what I've
typed isn't unique.  My standard mode of operation is that I type as
much as I think I need to and hit TAB.  Then, based on what I see, I
type enough extra to get a unique match.  This process is all
subconscious and is the one I've used since the days of the
AT&T-encumbered enhanced csh with completion from the late '80s. :-)

So.... if someone could humor me and summarize what has been firmly
decided (and committed to CVS) on this issue and what options are
still under discussion, I'd be grateful.  In the mean time, maybe I'll
grab the latest CVS release and/or play with menu completion.  Any
guestimates on when a dev7 will be released?  Such an event would be
announced to this list, right?

Thanks for your help.

--
E. Jay Berkenbilt (ejb@ql.org)  |  http://www.ql.org/q/

RE: completion widgets in menu selection

[Andrej Borsenkow]

> In the last several weeks, I raised three issues on this list:
>
>  1. a|TAB being broken (which was fixed and I assume committed to
>     CVS)
>
>  2. being able to more flexibly say that the completion rules for one
>     command should be identical to another (as in _rlogin) without
>     requiring Draconian restrictions on how completion functions
>     should be organized
>
>  3. (my favorite) being able to insert all completions that match the
>     current shell globbing expression into the commandline.
>
> The first issue is obviously resolved.  The second issue has generated
> less traffic than the third and I haven't had much trouble following.
> It seems like a good track is being followed.
>
> On the final issue, I'm confused about where things are going.  I've
> decided that, as Bart suspected all along, I don't really like TAB
> automatically "expanding" my glob expression even in the case of cvs
> add.  What I think I really like is the _insert_all_matches option.
> That way I can hit TAB to see what would complete without actually
> having the completion be done, and if I'm satisfied, do something like
> ^Xi to do the expansion.  Has this functionality actually been added,
> or was it just discussed?
>

Hey ho! Now I'm not alone! :-)))

Yes, all prerequisites are  implemented in current CVS. What is missing, is
the widget/key binding itself, but if you use example from docs verbatim, it
works. I've tried it and I confirm it.

If you have suggestions what this _insert_all_matches should do - you are
welcome. The difference between example and my version is that in my version
you could hit ^Xi - and if there was no list, it called normal completion. Is
this interesting? Example from docs will work only after existing list has
already been generated.

-andrej

Re: completion widgets in menu selection

[E. Jay Berkenbilt]

>   > . . . 
>   >
>   >  3. (my favorite) being able to insert all completions that match the
>   >     current shell globbing expression into the commandline.
>   >
>   > 
>   > . . . 
>
>   Hey ho! Now I'm not alone! :-)))
>
>   Yes, all prerequisites are  implemented in current CVS. What is missing, is
>   the widget/key binding itself, but if you use example from docs verbatim, it
>   works. I've tried it and I confirm it.

I just grabbed the latest CVS sources.  Care to give me a hint about
where in the documentation I should look or what I should search for?
:-) I'm not having any luck finding anything about that.

RE: completion widgets in menu selection

[Andrej Borsenkow]

> >
> >   Yes, all prerequisites are  implemented in current CVS. What is
> missing, is
> >   the widget/key binding itself, but if you use example from docs
> verbatim, it
> >   works. I've tried it and I confirm it.
>
> I just grabbed the latest CVS sources.  Care to give me a hint about
> where in the documentation I should look or what I should search for?

I'm using info; it is in "Completion system" - "Control Functions",
_all_matches completer or somewhere in 'man zshcompsys'. Small explanation:

example at the end of _all_matches description will simply include all items
completion system has generated at this point. But it won't do any completion
itself. What exactly completion system generates, depends on your completer
style for regular completion. My standard setting is

zstyle ':completion:*' completer _oldlist _complete _match

here first normal completion (where word on the line is taken verbatim) is
tried. If it fails (generates no matches), zsh tries to treat word on the line
as pattern and match possible completions against it. _oldlist just ensures
that zsh will reuse old list if it exists - it is not striclty neccessary and
is my personal preference.

I do not use _expand as part of normal completion (I prefer explict expansion
if needed) and I had problems with _correct/_approximate and path completion
(it was way too slow) - but, I have to try again.

Note, that _match is not related to file name globbing. It will equally well
work e.g. for any cvs completions (even those, that complete remote objects,
like modules). So, you can do something like 'cvs co *foo' to checkout
everything that ends with foo, even with remote repository

> :-) I'm not having any luck finding anything about that.
>

We desperately need somebody with fresh look to proofread zsh docs.

-andrej