GNU bug report logs -
#49204
28.0.50; How to create new file in project by project-find-file
Previous Next
Reported by: Giáp Trần <giaptx <at> mht.vn>
Date: Thu, 24 Jun 2021 10:34:02 UTC
Severity: normal
Found in version 28.0.50
Done: Dmitry Gutov <dgutov <at> yandex.ru>
Bug is archived. No further changes may be made.
To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 49204 in the body.
You can then email your comments to 49204 AT debbugs.gnu.org in the normal way.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Thu, 24 Jun 2021 10:34:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
Giáp Trần <giaptx <at> mht.vn>
:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org
.
(Thu, 24 Jun 2021 10:34:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Sun, 27 Jun 2021 00:09:02 GMT)
Full text and
rfc822 format available.
Message #8 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 28 Jun 2021 03:07:01 GMT)
Full text and
rfc822 format available.
Message #11 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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 <at> 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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Tue, 29 Jun 2021 13:50:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Wed, 30 Jun 2021 04:45:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Sun, 04 Jul 2021 01:08:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 05 Jul 2021 04:04:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Sun, 18 Jul 2021 00:47:02 GMT)
Full text and
rfc822 format available.
Message #26 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 19 Jul 2021 02:16:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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,
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 19 Jul 2021 15:44:02 GMT)
Full text and
rfc822 format available.
Message #32 received at 49204 <at> debbugs.gnu.org (full text, mbox):
>> 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]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Tue, 20 Jul 2021 02:17:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Tue, 20 Jul 2021 02:19:01 GMT)
Full text and
rfc822 format available.
Message #38 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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.
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Tue, 20 Jul 2021 02:59:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Wed, 21 Jul 2021 00:30:02 GMT)
Full text and
rfc822 format available.
Message #44 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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?
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Wed, 21 Jul 2021 01:35:01 GMT)
Full text and
rfc822 format available.
Message #47 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 02 Aug 2021 11:38:02 GMT)
Full text and
rfc822 format available.
Message #50 received at 49204 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
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?
[project-find-file-confirm-non-match.diff (text/x-patch, attachment)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org
:
bug#49204
; Package
emacs
.
(Mon, 02 Aug 2021 13:43:02 GMT)
Full text and
rfc822 format available.
Message #53 received at 49204 <at> debbugs.gnu.org (full text, mbox):
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!
Reply sent
to
Dmitry Gutov <dgutov <at> yandex.ru>
:
You have taken responsibility.
(Fri, 06 Aug 2021 00:32:02 GMT)
Full text and
rfc822 format available.
Notification sent
to
Giáp Trần <giaptx <at> mht.vn>
:
bug acknowledged by developer.
(Fri, 06 Aug 2021 00:32:02 GMT)
Full text and
rfc822 format available.
Message #58 received at 49204-done <at> debbugs.gnu.org (full text, mbox):
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 archived.
Request was from
Debbugs Internal Request <help-debbugs <at> gnu.org>
to
internal_control <at> debbugs.gnu.org
.
(Fri, 03 Sep 2021 11:24:04 GMT)
Full text and
rfc822 format available.
This bug report was last modified 2 years and 233 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.