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

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 70833 in the body.
You can then email your comments to 70833 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: bug-gnu-emacs <at> gnu.org
Cc: dmitry <at> gutov.dev
Subject: 29.2.50; project-current: allow control of the prompt string
Date: Wed, 08 May 2024 10:05:51 -0400

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.

Message #8 received at 70833 <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>, 70833 <at> debbugs.gnu.org
Subject: Re: bug#70833: 29.2.50; project-current: allow control of the prompt
 string
Date: Fri, 10 May 2024 04:57:23 +0300

[Message part 1 (text/plain, inline)]

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.

[maybe-prompt-prompt.diff (text/x-patch, attachment)]

Message #11 received at 70833 <at> debbugs.gnu.org (full text, mbox):

From: Spencer Baugh <sbaugh <at> janestreet.com>
To: Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 70833 <at> debbugs.gnu.org
Subject: Re: bug#70833: 29.2.50; project-current: allow control of the
 prompt string
Date: Fri, 04 Oct 2024 10:06:32 -0400

Dmitry Gutov <dmitry <at> 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.

Message #16 received at 70833-done <at> debbugs.gnu.org (full text, mbox):

From: Dmitry Gutov <dmitry <at> gutov.dev>
To: Spencer Baugh <sbaugh <at> janestreet.com>
Cc: 70833-done <at> debbugs.gnu.org
Subject: Re: bug#70833: 29.2.50; project-current: allow control of the prompt
 string
Date: Tue, 8 Oct 2024 02:13:01 +0300

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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.