bug#70833: 29.2.50; project-current: allow control of the prompt string

bug#70833: 29.2.50; project-current: allow control of the prompt string

[Spencer Baugh]

It would be nice to be able to control the prompt string that
project-current uses when prompting for a project.  Ideally, by passing
a string for the MAYBE-PROMPT argument.

This is useful when using project-current in functions which should
operate on the current project normally, but which might be run outside
any project and in that case will prompt for a project.  The user might
be uncertain about what the project they'll input will be used for,
exactly.  It's useful for the prompt to remind them.

The prompt could be passed down as an argument to project-prompter, or
bound in a defvar for compatibility - either seems fine to me.

bug#70833: 29.2.50; project-current: allow control of the prompt string

[Dmitry Gutov]

[-- Attachment #1: Type: text/plain, Size: 1391 bytes --]

Hi Spencer,

On 08/05/2024 17:05, Spencer Baugh wrote:
> 
> It would be nice to be able to control the prompt string that
> project-current uses when prompting for a project.  Ideally, by passing
> a string for the MAYBE-PROMPT argument.
> 
> This is useful when using project-current in functions which should
> operate on the current project normally, but which might be run outside
> any project and in that case will prompt for a project.  The user might
> be uncertain about what the project they'll input will be used for,
> exactly.  It's useful for the prompt to remind them.
> 
> The prompt could be passed down as an argument to project-prompter, or
> bound in a defvar for compatibility - either seems fine to me.

Aside from documentation changes, and the backward incompatibility 
pains, this looks easy enough to do.

Why do you say that that the lexical argument is better than a dynamic 
one in this case? Just wondering if you see a particular reason.

Also, I wonder if we perhaps should pass not the entire prompt but some 
"purpose hint". For example, the argument could look like "find-file", 
and then the prompt would be rendered as

   Select project [find-file]:

or however else the prompter implementation decides (perhaps it uses 
some other different UI where another text arrangement would be better). 
Just a thought -- I'm probably over-complicating things.


[-- Attachment #2: maybe-prompt-prompt.diff --]
[-- Type: text/x-patch, Size: 2378 bytes --]

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 52fe4df9080..b36cd1989f9 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -235,7 +235,9 @@ project-current
      (pr)
      ((unless project-current-directory-override
         maybe-prompt)
-      (setq directory (funcall project-prompter)
+      (setq directory (if (stringp maybe-prompt)
+                          (funcall project-prompter maybe-prompt)
+                        (funcall project-prompter))
             pr (project--find-in-directory directory))))
     (when maybe-prompt
       (if pr
@@ -1819,7 +1821,7 @@ project-forget-project
 
 (defvar project--dir-history)
 
-(defun project-prompt-project-dir ()
+(defun project-prompt-project-dir (&optional prompt)
   "Prompt the user for a directory that is one of the known project roots.
 The project is chosen among projects known from the project list,
 see `project-list-file'.
@@ -1837,14 +1839,15 @@ project-prompt-project-dir
       ;; If the user simply pressed RET, do this again until they don't.
       (setq pr-dir
             (let (history-add-new-input)
-              (completing-read "Select project: " choices nil t nil 'project--dir-history))))
+              (completing-read (or prompt "Select project: ")
+                               choices nil t nil 'project--dir-history))))
     (if (equal pr-dir dir-choice)
         (read-directory-name "Select directory: " default-directory nil t)
       pr-dir)))
 
 (defvar project--name-history)
 
-(defun project-prompt-project-name ()
+(defun project-prompt-project-name (&optional prompt)
   "Prompt the user for a project, by name, that is one of the known project roots.
 The project is chosen among projects known from the project list,
 see `project-list-file'.
@@ -1872,7 +1875,8 @@ project-prompt-project-name
       ;; If the user simply pressed RET, do this again until they don't.
       (setq pr-name
             (let (history-add-new-input)
-              (completing-read "Select project: " table nil t nil 'project--name-history))))
+              (completing-read (or prompt "Select project: ")
+                               table nil t nil 'project--name-history))))
     (if (equal pr-name dir-choice)
         (read-directory-name "Select directory: " default-directory nil t)
       (let ((proj (assoc pr-name choices)))

bug#70833: 29.2.50; project-current: allow control of the prompt string

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

Dmitry Gutov <dmitry@gutov.dev> writes:

> Hi Spencer,
>
> On 08/05/2024 17:05, Spencer Baugh wrote:
>> It would be nice to be able to control the prompt string that
>> project-current uses when prompting for a project.  Ideally, by passing
>> a string for the MAYBE-PROMPT argument.
>> This is useful when using project-current in functions which should
>> operate on the current project normally, but which might be run outside
>> any project and in that case will prompt for a project.  The user might
>> be uncertain about what the project they'll input will be used for,
>> exactly.  It's useful for the prompt to remind them.
>> The prompt could be passed down as an argument to project-prompter,
>> or
>> bound in a defvar for compatibility - either seems fine to me.
>
> Aside from documentation changes, and the backward incompatibility
> pains, this looks easy enough to do.

Your change looks good to me.

> Why do you say that that the lexical argument is better than a dynamic
> one in this case? Just wondering if you see a particular reason.

No particular reason.

> Also, I wonder if we perhaps should pass not the entire prompt but
> some "purpose hint". For example, the argument could look like
> "find-file", and then the prompt would be rendered as
>
>   Select project [find-file]:
>
> or however else the prompter implementation decides (perhaps it uses
> some other different UI where another text arrangement would be
> better). Just a thought -- I'm probably over-complicating things.

Hm... I'm not sure about that, but this does make me realize that the
prompt should probably be passed as just "Select project", without the
": ".  Then we pass both our prompt and a custom prompt through
format-prompt.  That would be useful if a project-prompter ever wants to
support a default value, or a user has redefined format-prompt or
something.

bug#70833: 29.2.50; project-current: allow control of the prompt string

[Dmitry Gutov]

On 04/10/2024 17:06, Spencer Baugh wrote:

>> Also, I wonder if we perhaps should pass not the entire prompt but
>> some "purpose hint". For example, the argument could look like
>> "find-file", and then the prompt would be rendered as
>>
>>    Select project [find-file]:
>>
>> or however else the prompter implementation decides (perhaps it uses
>> some other different UI where another text arrangement would be
>> better). Just a thought -- I'm probably over-complicating things.
> 
> Hm... I'm not sure about that,

Okay, let's not over-complicate things.

If a custom prompter wanted to dispatch on that argument to show a 
fancier UI, it might as well check against a set of known string prompts.

> but this does make me realize that the
> prompt should probably be passed as just "Select project", without the
> ": ".  Then we pass both our prompt and a custom prompt through
> format-prompt.  That would be useful if a project-prompter ever wants to
> support a default value, or a user has redefined format-prompt or
> something.

That makes sense: we don't have a default in the built-in prompters, but 
each custom one should be able to choose that for itself.

Now in master, commit 9904376c797.

Note the built-in ones don't use format-prompt yet, for compatibility.