From: Sven Wischnowsky <wischnow@informatik.hu-berlin.de>
To: zsh-workers@sunsite.auc.dk
Subject: Re: PATCH: _insert_all_matches bindable command
Date: Wed, 4 Oct 2000 13:28:46 +0200 (MET DST) [thread overview]
Message-ID: <200010041128.NAA09491@beta.informatik.hu-berlin.de> (raw)
In-Reply-To: "Andrej Borsenkow"'s message of Wed, 20 Sep 2000 15:08:32 +0400
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
next reply other threads:[~2000-10-04 11:29 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2000-10-04 11:28 Sven Wischnowsky [this message]
[not found] <1000919021428.ZM30137@candle.brasslantern.com>
2000-09-20 11:08 ` Andrej Borsenkow
2000-09-22 15:13 ` Bart Schaefer
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200010041128.NAA09491@beta.informatik.hu-berlin.de \
--to=wischnow@informatik.hu-berlin.de \
--cc=zsh-workers@sunsite.auc.dk \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).