bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#49204: 28.0.50; How to create new file in project by project-find-fi


From: Dmitry Gutov
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
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0

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: project-find-file-confirm-non-match.diff
Description: Text Data


reply via email to

[Prev in Thread] Current Thread [Next in Thread]