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

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

[Giáp Trần]

Hi Developers,

I'm trying to migrate from projectile package to project(0.6.0). That
is amazing.

Today I see I can
not create a new file by using `project-find-file.

I wish we can create a new file with `project-find-file when the file is
not in candidates as `find-file function do.

Thanks.

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

[Dmitry Gutov]

Hi!

On 24.06.2021 10:17, Giáp Trần wrote:

> I'm trying to migrate from projectile package to project(0.6.0). That
> is amazing.
> 
> Today I see I can
> not create a new file by using `project-find-file.
> 
> I wish we can create a new file with `project-find-file when the file is
> not in candidates as `find-file function do.

Any particular reason you'd want to do that? Do you want to bind this 
command to `C-x C-f` instead of `find-file`?

I've always figured we need the existing binding for a lot of cases 
anyway: it's often faster than project-find-file, and it's easier to use 
to create a file in the current directory (or nearby). There could be no 
current project (project-find-file will then ask you to choose one, and 
that's a nuisance).

And having the REQUIRE-MATCH behavior is nice to avoid typos.

That said, if you can describe the desired behavior, I could live with a 
user option. Bonus points for submitting a patch.

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

[Giáp Trần]

Hi Dmitry Gutov,

> That said, if you can describe the desired behavior, I could live with a
> user option. Bonus points for submitting a patch.

I have some cases as below:
1. I'm working on project A, and I believe I can find a file-b in
project B/src/test. Then I switch project by project-switch-project
and using project-find-file to lookup him, but I'm not lucky the
file-b is not existed in project-B/src/test so I want to create this
file now without exit project-find-file
2. I want to use project-find-file to create a new file because I have
an overview of all subfolder levels in all folders. With find-file I
don't have this overview
These are normal case occur everyday on me.

Thanks,

On Sun, Jun 27, 2021 at 7:07 AM Dmitry Gutov <dgutov@yandex.ru> wrote:
>
> Hi!
>
> On 24.06.2021 10:17, Giáp Trần wrote:
>
> > I'm trying to migrate from projectile package to project(0.6.0). That
> > is amazing.
> >
> > Today I see I can
> > not create a new file by using `project-find-file.
> >
> > I wish we can create a new file with `project-find-file when the file is
> > not in candidates as `find-file function do.
>
> Any particular reason you'd want to do that? Do you want to bind this
> command to `C-x C-f` instead of `find-file`?
>
> I've always figured we need the existing binding for a lot of cases
> anyway: it's often faster than project-find-file, and it's easier to use
> to create a file in the current directory (or nearby). There could be no
> current project (project-find-file will then ask you to choose one, and
> that's a nuisance).
>
> And having the REQUIRE-MATCH behavior is nice to avoid typos.
>
> That said, if you can describe the desired behavior, I could live with a
> user option. Bonus points for submitting a patch.

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

[Dmitry Gutov]

Hi!

On 28.06.2021 05:07, Giáp Trần wrote:
>> That said, if you can describe the desired behavior, I could live with a
>> user option. Bonus points for submitting a patch.
> I have some cases as below:
> 1. I'm working on project A, and I believe I can find a file-b in
> project B/src/test. Then I switch project by project-switch-project
> and using project-find-file to lookup him, but I'm not lucky the
> file-b is not existed in project-B/src/test so I want to create this
> file now without exit project-find-file
> 2. I want to use project-find-file to create a new file because I have
> an overview of all subfolder levels in all folders. With find-file I
> don't have this overview
> These are normal case occur everyday on me.

Thanks for the explanations. You previously wrote about Projectile. Does 
it enable this workflow?

I wonder how we can reconcile this requirement with the "find name at 
point" behavior: we use whatever string at point that looks similar 
enough to a file name (or a part of it). To avoid mistakes, we currently 
even call completing-read again if the first finished input doesn't 
match any files.

If the command allows non-matching input, having a default value that 
doesn't necessarily match any file names exactly will be a problem. 
Moving it from DEFAULT to INITIAL-INPUT shouldn't make a difference either.

Ideas welcome, everybody.

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

[Giap Tran]

On 6/29/21 8:49 PM, Dmitry Gutov wrote:
>>
> 
> Thanks for the explanations. You previously wrote about Projectile. Does 
> it enable this workflow?

Yes, as I see projectile support this feature by default (1). I used it 
before

> I wonder how we can reconcile this requirement with the "find name at 
> point" behavior: we use whatever string at point that looks similar 
> enough to a file name (or a part of it). To avoid mistakes, we currently 
> even call completing-read again if the first finished input doesn't 
> match any files.
> 
> If the command allows non-matching input, having a default value that 
> doesn't necessarily match any file names exactly will be a problem. 
> Moving it from DEFAULT to INITIAL-INPUT shouldn't make a difference either.

Thanks for clarifying, I will try to override 
project--completing-read-strict func when calling completing-read with 
REQUIRE-MATCH is nil

(1) - 
https://github.com/bbatsov/projectile/blob/6b88b69ecd7e6f2b6bbcae0b68026a486be516a4/projectile.el#L1885

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

[Dmitry Gutov]

On 30.06.2021 07:44, Giap Tran wrote:
> On 6/29/21 8:49 PM, Dmitry Gutov wrote:
>>>
>>
>> Thanks for the explanations. You previously wrote about Projectile. 
>> Does it enable this workflow?
> 
> Yes, as I see projectile support this feature by default (1). I used it 
> before

Thanks for the link.

projectile-find-file doesn't specify any INITIAL-INPUT when calling 
projectile-completing-read, so Projectile seems exempt from this dilemma 
that I described.

>> I wonder how we can reconcile this requirement with the "find name at 
>> point" behavior: we use whatever string at point that looks similar 
>> enough to a file name (or a part of it). To avoid mistakes, we 
>> currently even call completing-read again if the first finished input 
>> doesn't match any files.
>>
>> If the command allows non-matching input, having a default value that 
>> doesn't necessarily match any file names exactly will be a problem. 
>> Moving it from DEFAULT to INITIAL-INPUT shouldn't make a difference 
>> either.
> 
> Thanks for clarifying, I will try to override 
> project--completing-read-strict func when calling completing-read with 
> REQUIRE-MATCH is nil
> 
> (1) - 
> https://github.com/bbatsov/projectile/blob/6b88b69ecd7e6f2b6bbcae0b68026a486be516a4/projectile.el#L1885 

Better than that, you can set project-read-file-name-function to a 
function with the same signature that uses REQUIRE-MATCH=nil.

But I suppose an override for project--completing-read-strict might 
require less code, if you still want to retain the "completion from 
relative names" part of behavior from project--read-file-cpd-relative.

The flip side is someday you might have to deal with breakage when we 
have to make a change to project--completing-read-strict (which is a 
"private" function) or stop using it.

Let me know which approach you choose in the end, and how it works out.

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

[Giap Tran]

On 7/4/21 8:07 AM, Dmitry Gutov wrote:
> But I suppose an override for project--completing-read-strict might 
> require less code, if you still want to retain the "completion from 
> relative names" part of behavior from project--read-file-cpd-relative.
> 
> The flip side is someday you might have to deal with breakage when we 
> have to make a change to project--completing-read-strict (which is a 
> "private" function) or stop using it.
> 
> Let me know which approach you choose in the end, and how it works out.

Ya, I'm overriding project--completing-read-strict. It looks good to me.
As I see I still can use find a file at point by M-n. So don't 
understand why you said we can not use find file at point anymore if we 
set REQUIRE-MATCH is nil

Do you want this file to exist, right? IMO, If file is not exist
we can know it by look at minibuffer.

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

[Dmitry Gutov]

On 05.07.2021 07:03, Giap Tran wrote:
> On 7/4/21 8:07 AM, Dmitry Gutov wrote:
>> But I suppose an override for project--completing-read-strict might 
>> require less code, if you still want to retain the "completion from 
>> relative names" part of behavior from project--read-file-cpd-relative.
>>
>> The flip side is someday you might have to deal with breakage when we 
>> have to make a change to project--completing-read-strict (which is a 
>> "private" function) or stop using it.
>>
>> Let me know which approach you choose in the end, and how it works out.
> 
> Ya, I'm overriding project--completing-read-strict. It looks good to me.

Excellent.

> As I see I still can use find a file at point by M-n. So don't 
> understand why you said we can not use find file at point anymore if we 
> set REQUIRE-MATCH is nil

Right, but then if you press RET, the file will be created.

If, for example, the text around point is 'compile.el', and you call 
project-find-file and press RET right away, you're not going to visit 
(or create) a file named 'compile.el' in the project root, you're going 
to see the list filered with 'compile.el' as initial-input instead.

Perhaps we should change the above workflow to be more "standard", but 
IIRC the existing one was requested to be this way, and has received 
surprisingly little complaints over the years.

> Do you want this file to exist, right? IMO, If file is not exist
> we can know it by look at minibuffer.

How can we know? Do you mean that it tells you that by asking to confirm 
after you press RET?

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

[Giap Tran]

On 7/18/21 7:46 AM, Dmitry Gutov wrote:
> 
> 
> Perhaps we should change the above workflow to be more "standard", but 
> IIRC the existing one was requested to be this way, and has received 
> surprisingly little complaints over the years.

I checked how the find-file func works. I see we should learn find-file 
behavior.

That means `project-find-file' will not set the default file instead 
using M-n (next-history-element) if the user wants to use find file at 
point.

By using this behavior, we can go to in dired mode of project root by 
default. Currently, we can not jump to dired mode if the text around 
point 'compile.el'

> How can we know? Do you mean that it tells you that by asking to confirm 
> after you press RET?

I mean we have to looks by our eyes :P

Oh, you mentioned "confirm". Do you use magit? I see this package has a 
good UI/UX by default. If the user wants to push to a new branch is not 
exist, magit will a "confirm" question.


Regards,

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

[Juri Linkov]

>> How can we know? Do you mean that it tells you that by asking to confirm
>> after you press RET?
>
> I mean we have to looks by our eyes :P
>
> Oh, you mentioned "confirm". Do you use magit? I see this package has
> a good UI/UX by default. If the user wants to push to a new branch is not
> exist, magit will a "confirm" question.

The same way as switch-to-buffer confirms a non-existent buffer with:

  C-x b non-existent TAB RET [Confirm]

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

[Dmitry Gutov]

On 19.07.2021 18:20, Juri Linkov wrote:
> The same way as switch-to-buffer confirms a non-existent buffer with:
> 
>    C-x b non-existent TAB RET [Confirm]

switch-to-buffer uses read-buffer-to-switch, which delegates to 
read-buffer, a standard function.

read-file-name uses, say, read-file-name-default. Neither delegate to a 
user-provided completion table, though. So we might have to reimplement 
the check-and-prompt interface.

Would someone like to propose a patch?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov [2021-07-20 05:15:59] wrote:
> On 19.07.2021 18:20, Juri Linkov wrote:
>> The same way as switch-to-buffer confirms a non-existent buffer with:
>>    C-x b non-existent TAB RET [Confirm]
>
> switch-to-buffer uses read-buffer-to-switch, which delegates to read-buffer,
> a standard function.
>
> read-file-name uses, say, read-file-name-default. Neither delegate to
> a user-provided completion table, though. So we might have to reimplement
> the check-and-prompt interface.

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`).


        Stefan

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

[Dmitry Gutov]

On 20.07.2021 05:58, 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).

corfu and vertico support 'confirm', but they're probably not popular 
enough yet to justify that choice.

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?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Dmitry Gutov [2021-07-21 03:29:43] wrote:
> On 20.07.2021 05:58, 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.

> 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.


        Stefan

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

[Dmitry Gutov]

[-- 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 ()

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

[Giap Tran]

On 8/2/21 6:37 PM, Dmitry Gutov wrote:
> 
> The attached patch seems to solve that. Does the behavior look good to 
> everyone?

Looks good to me. I will apply this patch immediately to my configuration.

Thank you very much!

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

[Dmitry Gutov]

On 02.08.2021 16:42, Giap Tran wrote:
> Looks good to me. I will apply this patch immediately to my configuration.
> 
> Thank you very much!

I've pushed the change now. Thanks for testing.

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

[Dmitry Gutov]

On 19.07.2021 05:15, Giap Tran wrote:

> That means `project-find-file' will not set the default file instead 
> using M-n (next-history-element) if the user wants to use find file at 
> point.

I could live with that.

> By using this behavior, we can go to in dired mode of project root by 
> default.

That seems beneficial (though we have a separate command for that).

>> How can we know? Do you mean that it tells you that by asking to 
>> confirm after you press RET?
> 
> I mean we have to looks by our eyes :P
> 
> Oh, you mentioned "confirm". Do you use magit? I see this package has a 
> good UI/UX by default. If the user wants to push to a new branch is not 
> exist, magit will a "confirm" question.

I've used Magit several years ago. It has a well-deserved reputation, 
but it also has a lot of custom code and interface elements, so it's 
often not so easy to follow its lead when working on a feature in Emacs 
core.