From: Dmitry Gutov <dgutov@yandex.ru>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: Giap Tran <giaptx@mht.vn>,
Stephen Leake <stephen_leake@stephe-leake.org>,
49204@debbugs.gnu.org, Juri Linkov <juri@linkov.net>
Subject: bug#49204: 28.0.50; How to create new file in project by project-find-file
Date: Mon, 2 Aug 2021 14:37:41 +0300 [thread overview]
Message-ID: <49ce60bf-9c8d-818f-a0a4-4010a7e56462@yandex.ru> (raw)
In-Reply-To: <jwv5yx43147.fsf-monnier+emacs@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 1613 bytes --]
On 21.07.2021 04:34, Stefan Monnier via Bug reports for GNU Emacs, the
Swiss army knife of text editors wrote:
>>> I haven't followed the discussion, so I might be off, but I think what
>>> is described above is something you can get simply by passing the
>>> appropriate value for `mustmatch` to `completing-read` and friends
>>> (including `read-file-name`).
>> Probably not: most third-party completion functions out there don't support
>> any non-nil values of that argument other than t (or treat them like t).
>
> Their loss.
Actually, ivy-completing-read treats 'confirm' the same as nil.
Oh well.
>> And suppose we chose to use 'confirm', would a neutral prompt "Confirm"
>> without clarification, as opposed to something like "File does not exist;
>> Create?", be our best choice?
>
> The same question comes up for `C-x C-f` (and `C-x C-b`).
>
> So far the answer we have chosen is "yes". We can revisit it,
> of course. Just like we may want to revisit the way `mustmatch` works,
> but at least there is an existing "standard protocol" to get that kind
> of behavior and I can't think of a good reason why `project-find-file`
> should behave very differently from `find-file` in this respect.
Fair enough.
Trying this approach, I seem to recall the main problem we tried to
solve originally: the string passed as DEFAULT was returned as the value
entered by the user if they simply pressed RET, with no additional check
for whether it actually matches any of the file names (or the "Confirm"
prompt).
The attached patch seems to solve that. Does the behavior look good to
everyone?
[-- Attachment #2: project-find-file-confirm-non-match.diff --]
[-- Type: text/x-patch, Size: 1687 bytes --]
diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 0e73286426..6a330ecb2b 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -879,23 +879,16 @@ project-find-file-in
(defun project--completing-read-strict (prompt
collection &optional predicate
hist default)
- ;; Tried both expanding the default before showing the prompt, and
- ;; removing it when it has no matches. Neither seems natural
- ;; enough. Removal is confusing; early expansion makes the prompt
- ;; too long.
- (let* ((new-prompt (if (and default (not (string-equal default "")))
- (format "%s (default %s): " prompt default)
- (format "%s: " prompt)))
- (res (completing-read new-prompt
- collection predicate t
- nil ;; initial-input
- hist default)))
- (when (and (equal res default)
- (not (test-completion res collection predicate)))
- (setq res
- (completing-read (format "%s: " prompt)
- collection predicate t res hist nil)))
- res))
+ (minibuffer-with-setup-hook
+ (lambda ()
+ (setq-local minibuffer-default-add-function
+ (lambda ()
+ (let ((minibuffer-default default))
+ (minibuffer-default-add-completions)))))
+ (completing-read prompt
+ collection predicate 'confirm
+ nil
+ hist)))
;;;###autoload
(defun project-dired ()
next prev parent reply other threads:[~2021-08-02 11:37 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-24 7:17 bug#49204: 28.0.50; How to create new file in project by project-find-file Giáp Trần
2021-06-27 0:07 ` Dmitry Gutov
2021-06-28 2:07 ` Giáp Trần
2021-06-29 13:49 ` Dmitry Gutov
2021-06-30 4:44 ` Giap Tran
2021-07-04 1:07 ` Dmitry Gutov
2021-07-05 4:03 ` Giap Tran
2021-07-18 0:46 ` Dmitry Gutov
2021-07-19 2:15 ` Giap Tran
2021-07-19 15:20 ` Juri Linkov
2021-07-20 2:15 ` Dmitry Gutov
2021-07-20 2:58 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-07-21 0:29 ` Dmitry Gutov
2021-07-21 1:34 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2021-08-02 11:37 ` Dmitry Gutov [this message]
2021-08-02 13:42 ` Giap Tran
2021-08-06 0:31 ` Dmitry Gutov
2021-07-20 2:18 ` 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=49ce60bf-9c8d-818f-a0a4-4010a7e56462@yandex.ru \
--to=dgutov@yandex.ru \
--cc=49204@debbugs.gnu.org \
--cc=giaptx@mht.vn \
--cc=juri@linkov.net \
--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).