PATCH: _insert_all_matches bindable command

PATCH: _insert_all_matches bindable command

[Andrej Borsenkow]

[Moved to zsh-workers]

> }
> } Well, in fact, I never do this with rmdir. [...]
> } I really use this with cvs add and cvs rm where it is great.
>
> So you have it restricted by style to :completion::complete:cvs* or
> something like that?  I could see where that would be useful, but I
> wouldn't want it in context :completion:* ...
>

Yes, exactly. It is very unlikely that somebody would like to *always* insert
all matches even for any particular command. For this reason I also never used
_expand *completer*. Trying expansion on every completion just seems too
general. (There is one more reason - IMHO expansion is context-independent
operation while normal completion is highly context-dependent. You just cannot
mix both).

For this reason here the proposed patch, that adds _insert_all_matches widget
bound to ^Xi. It can be used after any completion and standalone. It will
reuse existing list if available (controlled by old-list style, like in
_oldlist completer). Called standalone it will call normal completion and
insert all generated matches.

Some comments:

- it will reuse any exisitng list even if it's not appropriate. E.g. in case
of correction original word is listed as possible match, so ^Xi will insert it
as well. Another similar case is _expand. But in case of _expand you already
have the choice to insert all expansions.

- I could not find a way to supress suffix addition. It is weird as it is
added only to the last match anyway. Sven?

- it does not work inside of menu selection, because it accepts selected match
and clears list even before calling any widget. It does work in menu
completion. Sven will have the final word, but, may be, menu selection should
not accept the match and clear list at least for completion widgets. Also,
there is subtle difference between menu completion and menu selection - menu
selection adds space where menu completion does not. E.g.:

bor@itsrm2% l f*
fOo   foO   foo

(selection)

bor@itsrm2% l fOo
Completing file
fOo   foO   foo
(press `i')
bor@itsrm2% l fOo i
Completing file
fOo   foO   foo

(completion)

bor@itsrm2% ls fOo
Completing file
fOo   foO   foo
(press `i')
bor@itsrm2% ls fOoi
Completing file
fOo   foO   foo

I would really prefer the same behaviour in both cases.

Jay, would it be useful to you?

-andrej

sourceforge CVS server is down, so I just send the function itself (without
manual update). Coments?

====== cut here ======
#compdef -K _insert_all_matches complete-word \C-xi

setopt localoptions nullglob rcexpandparam extendedglob noshglob
unsetopt markdirs globsubst shwordsplit nounset ksharrays

local oldcurcontext="$curcontext" list ret

if [[ -z "$oldcurcontext" ]]; then
  curcontext="insert-all-matches:::"
else
  curcontext="insert-all-matches:${oldcurcontext#*:}"
fi

zstyle -s ":completion:${curcontext}:" old-list list

# If there is already an old list,
# and either the style :insert-all-matches:old-list is `always',
# or it is not `never', then insert the existing list
# (even if it was generated by another widget).
# Else just call completion and insert whatever matches it generated
# TODO: does not work in menu selection


if [[ -n $compstate[old_list] && $list != never &&
      $LASTWIDGET != _complete_help && $WIDGET != _complete_help ]]; then
    compstate[old_list]=keep
    compstate[insert]=all
    return 0
else
    curcontext="$oldcurcontext"
    _main_complete
    ret=$?
    compstate[insert]=all
    return $ret
fi

Re: PATCH: _insert_all_matches bindable command

[Bart Schaefer]

On Sep 20,  3:08pm, Andrej Borsenkow wrote:
}
} - I could not find a way to supress suffix addition. It is weird as it is
} added only to the last match anyway. Sven?

This happens any time you insert multiple matches.  Look at the code for
the add-space style in _expand -- it deliberately changes the compadd
command for each match in order to suppress the suffix or change it to
a space.

} sourceforge CVS server is down, so I just send the function itself

BTW, for those of you who don't get sourceforge user update mailings, the
scheduled downtime this weekend has been canceled, and will be sometime in
October instead.

} zstyle -s ":completion:${curcontext}:" old-list list
} 
} # If there is already an old list,
} # and either the style :insert-all-matches:old-list is `always',
                         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
                   :completion:insert-all-matches:* old-list  ??
} # or it is not `never', then insert the existing list
} # (even if it was generated by another widget).
} # Else just call completion and insert whatever matches it generated
} # TODO: does not work in menu selection
} 
} 
} if [[ -n $compstate[old_list] && $list != never &&
}       $LASTWIDGET != _complete_help && $WIDGET != _complete_help ]]; then

It's never possible for $WIDGET to be _complete_help, is it?  Both this
function and _complete_help must be separately bound to keystrokes.  You
would only need to test $WIDGET if this were a completer like _expand.

And you can do

  if [[ -n $compstate[old_list] ]] && $LASTWIDGET != _complete_help &&
  	! zstyle -t ":completion:${curcontext}:" old-list never; then

instead of separately fetching the value into $list and then testing it.

} else
}     curcontext="$oldcurcontext"
}     _main_complete
}     ret=$?
}     compstate[insert]=all
}     return $ret
} fi

Why reset the current context?  And why not just

    _main_complete && compstate[insert]=all

??  Do you really want to set compstate[insert] when the function is going
to return nonzero?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Suffixes and menu completion vs. menu selection

[Bart Schaefer]

On Sep 20,  3:08pm, Andrej Borsenkow wrote:
} Subject: PATCH: _insert_all_matches bindable command
}
} there is subtle difference between menu completion and menu selection - menu
} selection adds space where menu completion does not. E.g.:
} 
} bor@itsrm2% l f*
} fOo   foO   foo
} 
} (selection)
} 
} bor@itsrm2% l fOo
} Completing file
} fOo   foO   foo
} (press `i')
} bor@itsrm2% l fOo i
} Completing file
} fOo   foO   foo
} 
} (completion)
} 
} bor@itsrm2% ls fOo
} Completing file
} fOo   foO   foo
} (press `i')
} bor@itsrm2% ls fOoi
} Completing file
} fOo   foO   foo
} 
} I would really prefer the same behaviour in both cases.

In the case of menu selection, you're actually choosing a match. In the
case of menu completion, you're disambiguating the ambiguous prefix.

You could argue that menu selection should abort, rather than accept, on
self-insert, and thus restore the original string to the command line
before inserting the `i', but it should not both accept a match and
append the inserted character to it without also first inserting the
usual completion suffix.  The current menu selection behavior, though,
is intended to interrupt your typing as little as possible (i.e. you
needn't explicitly hit RETURN to accept the selection).

If you're suggesting that the menu completion menu should include the
suffix for each of the matches, even when that suffix is a space (it
already e.g. appends the slash for directories), that might be another
matter -- but it'd be a change from the way zsh has behaved for years.
If I have `ls f*<TAB>" and that results in `ls fOo ' (note space) plus
a listing, what happens when I press SPACE TAB ?  What visual feedback
is there that `f*<TAB><SPACE><TAB>' is not the same as `f*<TAB><TAB>'?

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Zsh: http://www.zsh.org | PHPerl Project: http://phperl.sourceforge.net   

Re: PATCH: _insert_all_matches bindable command

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> ... [ _insert_all_matches widget ]
> 
> Some comments:
> 
> ...
> 
> - I could not find a way to supress suffix addition. It is weird as it is
> added only to the last match anyway. Sven?

As I said in the mail I just sent, the insert-all-completions is
(still) a bit hackish, mostly I wasn't that sure about it myself and
because we got no reactions when it was added.

That suffix-on-the-last-match behaviour comes from the way it is
implemented, which is basically what a completion with accept-and-m-c
for all matches does. I didn't treat suffixes specially because 1) that
would have required extra code (not much), 2) I wasn't sure what would 
be preferred and 3) due to the auto-remove behaviour of all well-behaved
suffixes this didn't look like a big problem.

I could be convinced to change it: what do others think/prefer?

> - it does not work inside of menu selection, because it accepts selected match
> and clears list even before calling any widget. It does work in menu
> completion. Sven will have the final word, but, may be, menu selection should
> not accept the match and clear list at least for completion widgets. Also,
> there is subtle difference between menu completion and menu selection - menu
> selection adds space where menu completion does not. E.g.:

Bart already explained this. The special casing of completion widgets
you suggest... Hm. This /seems/ to make sense, except for the
then-difference between standard completion widgets (that have their
usual meaning in menu selection and don't leave at all) and
user-implemented widgets (where `user-implemented' would mean `added
without notification by compinit' for most users).

I wished there were a way to tell menu-selection which widget should
leave the match inserted and which shouldn't. But I can't think of a
clean way to do that.

Bye
 Sven


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