Re: PATCH: _insert_all_matches bindable command

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

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