From: "Roland Winkler" <winkler@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 12331@debbugs.gnu.org
Subject: bug#12331: 24.1; completing-read when COLLECTION has exactly one element
Date: Mon, 3 Sep 2012 11:26:07 -0500 [thread overview]
Message-ID: <20548.55839.962974.918916@gargle.gargle.HOWL> (raw)
In-Reply-To: <jwvligr5irq.fsf-monnier+emacs@gnu.org>
On Mon Sep 3 2012 Stefan Monnier wrote:
> > chosen it deliberately. If nonethless we ask the user what he or she
> > wants even though there is only one choice available, it much
> > reminds of one of my least favorite operating systems.
>
> The motivation sounds good, but the minibuffer prompt always offers one
> more choice, i.e. C-g. So accepting the only choice without prompting
> might end up being a bit too eager in some cases.
Sure, under any circumstances I would not want to make this a
default for completing-read. I merely suggest that there are
scenarios where shortcutting the invocation of the minibuffer can be
reasonable. And I hope you don't mind we give this a try for the
particular example of ibuffer-switch-to-saved-filter-groups
described in my previous email.
> I think so, yes. So I suggest you look for callers where that could be
> used, and if they are common enough, we could consider adding a special
> value of `require-match' which would allow such a short-circuiting.
The least questionable examples are, in my opinion, those cases
where the elements in the list COLLECTION reflect a choice the user
made earlier (such as COLLECTION being a user variable defaulting to
nil).
I'll see whether I'll find more cases of that kind.
Roland
next prev parent reply other threads:[~2012-09-03 16:26 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-02 1:38 bug#12331: 24.1; completing-read when COLLECTION has exactly one element Roland Winkler
2012-09-02 2:49 ` Drew Adams
2012-09-02 16:25 ` Roland Winkler
2012-09-03 13:42 ` Stefan Monnier
2012-09-03 16:26 ` Roland Winkler [this message]
2012-09-03 18:47 ` Stefan Monnier
2012-09-04 3:38 ` Stefan Monnier
2012-09-23 12:55 ` Roland Winkler
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=20548.55839.962974.918916@gargle.gargle.HOWL \
--to=winkler@gnu.org \
--cc=12331@debbugs.gnu.org \
--cc=monnier@iro.umontreal.ca \
/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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.