unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Slight confusion in project-find-file
@ 2021-09-13 14:07 Lars Ingebrigtsen
  2021-09-13 14:25 ` Manuel Uberti
  2021-09-13 22:03 ` Dmitry Gutov
  0 siblings, 2 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-13 14:07 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

I was looking at

*** 'project-find-file' doesn't use the string at point as default input.
Now it's only suggested as part of the "future history".

which comes from

commit fa895379d6166c52b89774a9e450a94c2e429dae
Author:     Dmitry Gutov <dgutov@yandex.ru>
AuthorDate: Fri Aug 6 03:30:10 2021 +0300

    Change how project-find-file's completion works
    
    * lisp/progmodes/project.el (project--completing-read-strict):
    Allow to choose a non-existent file, with confirmation
    (bug#49204).
    Don't use the string at point as a "real" default, and instead
    only include it in "future history": meaning, it will be inserted
    on 'M-n' (bug#49865).

And, indeed, it doesn't put anything in the default.  However, I'm
getting a bit confused trying to follow the logic:

(defun project-or-external-find-file ()
  "Visit a file (with completion) in the current project or external roots.

The completion default is the filename at point, determined by
`thing-at-point' (whether such file exists or not)."

So this says "default", but "completion default"...  (And same string in
project-find-file).  Also:

@findex project-find-file
[...]
belonging to the current project, and nothing else.  If there's a file
name at point, this command offers that file as the default to visit.

However, we basically end up calling:

(uniq-file-read "Prompt" nil nil nil "file-name")

there "file-name" is in the DEFAULT position, but is put in the "future
history".

Furthermore, `M-x project-find-file RET RET':

Debugger entered--Lisp error: (wrong-type-argument stringp nil)
  expand-file-name(nil)
  find-file-noselect(nil nil nil nil)
  find-file(nil)
  project-find-file-in(#("." 0 1 (fontified t)) ("~/src/emacs/trunk/") (vc . "~/src/emacs/trunk/"))
  project-find-file()
  funcall-interactively(project-find-file)

So I think this needs a bit more updating in the doc
strings/documentation/parameter names, and perhaps a different way of
erroring out on RET.  (Or even actually using the DEFAULT as a default.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no




^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Slight confusion in project-find-file
  2021-09-13 14:07 Slight confusion in project-find-file Lars Ingebrigtsen
@ 2021-09-13 14:25 ` Manuel Uberti
  2021-09-13 22:04   ` Dmitry Gutov
  2021-09-13 22:03 ` Dmitry Gutov
  1 sibling, 1 reply; 5+ messages in thread
From: Manuel Uberti @ 2021-09-13 14:25 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

On 13/09/21 16:07, Lars Ingebrigtsen wrote:
> Furthermore, `M-x project-find-file RET RET':
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>    expand-file-name(nil)
>    find-file-noselect(nil nil nil nil)
>    find-file(nil)
>    project-find-file-in(#("." 0 1 (fontified t)) ("~/src/emacs/trunk/") (vc . "~/src/emacs/trunk/"))
>    project-find-file()
>    funcall-interactively(project-find-file)

FWIW, doing `M-x project-find-file RET RET` on 'emacs -Q` I get 'Find file in 
/usr/local/bin: '

If I hit RET again a Dired buffer in that directory is shown.

I am running GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.18, cairo version 1.16.0) of 2021-09-13, on Ubuntu 20.04.

-- 
Manuel Uberti
www.manueluberti.eu



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Slight confusion in project-find-file
  2021-09-13 14:07 Slight confusion in project-find-file Lars Ingebrigtsen
  2021-09-13 14:25 ` Manuel Uberti
@ 2021-09-13 22:03 ` Dmitry Gutov
  2021-09-14 11:22   ` Lars Ingebrigtsen
  1 sibling, 1 reply; 5+ messages in thread
From: Dmitry Gutov @ 2021-09-13 22:03 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: emacs-devel

Hi!

On 13.09.2021 17:07, Lars Ingebrigtsen wrote:
> I was looking at
> 
> *** 'project-find-file' doesn't use the string at point as default input.
> Now it's only suggested as part of the "future history".
> 
> which comes from
> 
> commit fa895379d6166c52b89774a9e450a94c2e429dae
> Author:     Dmitry Gutov <dgutov@yandex.ru>
> AuthorDate: Fri Aug 6 03:30:10 2021 +0300
> 
>      Change how project-find-file's completion works
>      
>      * lisp/progmodes/project.el (project--completing-read-strict):
>      Allow to choose a non-existent file, with confirmation
>      (bug#49204).
>      Don't use the string at point as a "real" default, and instead
>      only include it in "future history": meaning, it will be inserted
>      on 'M-n' (bug#49865).
> 
> And, indeed, it doesn't put anything in the default.  However, I'm
> getting a bit confused trying to follow the logic:
> 
> (defun project-or-external-find-file ()
>    "Visit a file (with completion) in the current project or external roots.
> 
> The completion default is the filename at point, determined by
> `thing-at-point' (whether such file exists or not)."
> 
> So this says "default", but "completion default"...  (And same string in
> project-find-file).  Also:
> 
> @findex project-find-file
> [...]
> belonging to the current project, and nothing else.  If there's a file
> name at point, this command offers that file as the default to visit.
> 
> However, we basically end up calling:
> 
> (uniq-file-read "Prompt" nil nil nil "file-name")
> 
> there "file-name" is in the DEFAULT position, but is put in the "future
> history".

Indeed, there is a documentation problem. Part of it is that "future 
history" is not a well-known/defined concept, yet it is pretty useful.

Another - that future history is added to using a variable called 
minibuffer-default-add-function.

I've tried to improve the docs in commit 5a34b65a3b, not sure by how 
much. See how you like the result.

As far as using DEFAULT for default, it has been the previous behavior, 
and reasons for the change are hopefully apparent from the linked 
discussion. There have also been some other complaints/requests that 
have been resolved with that change.

> Furthermore, `M-x project-find-file RET RET':
> 
> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>    expand-file-name(nil)
>    find-file-noselect(nil nil nil nil)
>    find-file(nil)
>    project-find-file-in(#("." 0 1 (fontified t)) ("~/src/emacs/trunk/") (vc . "~/src/emacs/trunk/"))
>    project-find-file()
>    funcall-interactively(project-find-file)
> 
> So I think this needs a bit more updating in the doc
> strings/documentation/parameter names, and perhaps a different way of
> erroring out on RET.  (Or even actually using the DEFAULT as a default.)

This is really a bug of completing-read: returning "" on RET even if 
REQUIRE-MATCH is t. Probably a "feature" since the bug is decades old.

I've made it loop on RET instead now, hopefully it will resolve this 
scenario. FWIW, I couldn't repro the wrong-type-argument error here, but 
the behavior was surprising nevertheless.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Slight confusion in project-find-file
  2021-09-13 14:25 ` Manuel Uberti
@ 2021-09-13 22:04   ` Dmitry Gutov
  0 siblings, 0 replies; 5+ messages in thread
From: Dmitry Gutov @ 2021-09-13 22:04 UTC (permalink / raw)
  To: Manuel Uberti, Lars Ingebrigtsen; +Cc: emacs-devel

On 13.09.2021 17:25, Manuel Uberti wrote:
> On 13/09/21 16:07, Lars Ingebrigtsen wrote:
>> Furthermore, `M-x project-find-file RET RET':
>>
>> Debugger entered--Lisp error: (wrong-type-argument stringp nil)
>>    expand-file-name(nil)
>>    find-file-noselect(nil nil nil nil)
>>    find-file(nil)
>>    project-find-file-in(#("." 0 1 (fontified t)) 
>> ("~/src/emacs/trunk/") (vc . "~/src/emacs/trunk/"))
>>    project-find-file()
>>    funcall-interactively(project-find-file)
> 
> FWIW, doing `M-x project-find-file RET RET` on 'emacs -Q` I get 'Find 
> file in /usr/local/bin: '
> 
> If I hit RET again a Dired buffer in that directory is shown.

This should also improve with commit 9000aeaed4.



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: Slight confusion in project-find-file
  2021-09-13 22:03 ` Dmitry Gutov
@ 2021-09-14 11:22   ` Lars Ingebrigtsen
  0 siblings, 0 replies; 5+ messages in thread
From: Lars Ingebrigtsen @ 2021-09-14 11:22 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> I've tried to improve the docs in commit 5a34b65a3b, not sure by how
> much. See how you like the result.

Thanks; looks good to me.  (I've also adjusted the manual entry for the
command along similar lines now.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~2021-09-14 11:22 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-09-13 14:07 Slight confusion in project-find-file Lars Ingebrigtsen
2021-09-13 14:25 ` Manuel Uberti
2021-09-13 22:04   ` Dmitry Gutov
2021-09-13 22:03 ` Dmitry Gutov
2021-09-14 11:22   ` Lars Ingebrigtsen

Code repositories for project(s) associated with this 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 NNTP newsgroup(s).