From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Stephen Leake <stephen_leake@stephe-leake.org>,
emacs-devel <emacs-devel@gnu.org>
Subject: Re: make project--find-in-file generic, add interactive filename to project-find-file
Date: Sat, 30 Jan 2016 00:53:35 +0300 [thread overview]
Message-ID: <56ABDF5F.30404@yandex.ru> (raw)
In-Reply-To: <jwvio2cxz0e.fsf-monnier+emacs@gnu.org>
On 01/29/2016 05:05 PM, Stefan Monnier wrote:
> What problems do you foresee?
The usual lack of imagination?
With your generous encouragement, I wrote this:
(defun completing-read-strict (prompt
collection &optional predicate
hist default inherit-input-method)
(let* ((new-prompt (if default
(format "%s (default %s): " prompt default)
(format "%s: " prompt)))
(res (completing-read new-prompt
collection predicate t
nil hist default inherit-input-method))
try)
(if (and (equal res default)
(not (test-completion res collection predicate))
(not (and (setq try (car (completion-try-completion
res collection predicate (length
res))))
(setq res try)
(test-completion res collection predicate))))
(completing-read (format "%s: " prompt)
collection predicate t res hist nil
inherit-input-method)
res)))
I can use it in completing-read-strict to satisfy both points mentioned
previously. But after trying it out, I'm not sure about the general
applicability of the DEFAULT semantics here. It just seems awkward:
First, you tell the user that the default is so-and-so. But if they
choose to trust you (and aren't even surprised that the default isn't a
proper absolute filename), in the event that the default does not
correspond to a particular filename, you drop them into the same prompt
once again, but without the "default" part. And now the input contains
either:
- The previous "default" which has _some_ matches, and the user has to
figure that out, because I can't force the completing-read-function to
show the matches right away (the default one doesn't, it waits for me to
press TAB or RET; it's easier with icomplete-mode on).
- The previous "default" input which has no matches. The user doesn't
know about that right away either, so they must feel disoriented in this
case too. Seeing (no matches) at this step would be better.
- Nothing. Which could make sense if the previous "default" didn't
actually match anything, but the user must be even more surprised in
this case ("where did my default go?").
We could filter out the last two cases before calling
completing-read-strict, and don't pass DEFAULT in at all then, but this
makes the new function less necessary, and the first case remains confusing.
And as long as completing-read-strict, by itself, does allow the case of
"default that doesn't match anything", that makes me doubt its semantics.
next prev parent reply other threads:[~2016-01-29 21:53 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-01-28 1:04 make project--find-in-file generic, add interactive filename to project-find-file Stephen Leake
2016-01-28 9:21 ` Dmitry Gutov
2016-01-28 10:11 ` Stephen Leake
2016-01-28 10:36 ` Dmitry Gutov
2016-01-28 13:14 ` Stefan Monnier
2016-01-28 19:32 ` Dmitry Gutov
2016-01-28 21:11 ` Stefan Monnier
2016-01-28 21:22 ` Dmitry Gutov
2016-01-28 22:44 ` Stefan Monnier
2016-01-29 2:10 ` Dmitry Gutov
2016-01-29 2:57 ` Stefan Monnier
2016-01-29 4:20 ` Dmitry Gutov
2016-01-29 14:05 ` Stefan Monnier
2016-01-29 21:53 ` Dmitry Gutov [this message]
2016-01-31 6:18 ` Stefan Monnier
2016-01-31 14:02 ` Dmitry Gutov
2016-01-31 14:23 ` Stefan Monnier
2016-02-01 8:08 ` Dmitry Gutov
2016-02-01 13:40 ` Stefan Monnier
2016-01-29 2:05 ` Dmitry Gutov
2016-01-29 2:55 ` Stefan Monnier
2016-01-29 4:11 ` Dmitry Gutov
2016-01-29 14:03 ` Stefan Monnier
2016-01-29 21:35 ` Dmitry Gutov
2016-01-30 2:07 ` Stefan Monnier
2016-01-30 23:32 ` Juri Linkov
2016-01-31 0:40 ` Dmitry Gutov
2016-01-28 11:06 ` Stephen Leake
2016-01-28 11:11 ` Stephen Leake
2016-01-29 2:18 ` Dmitry Gutov
2016-01-29 23:55 ` Stephen Leake
2016-01-30 0:15 ` Dmitry Gutov
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=56ABDF5F.30404@yandex.ru \
--to=dgutov@yandex.ru \
--cc=emacs-devel@gnu.org \
--cc=monnier@iro.umontreal.ca \
--cc=stephen_leake@stephe-leake.org \
/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.savannah.gnu.org/cgit/emacs.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).