* bug#70833: 29.2.50; project-current: allow control of the prompt string @ 2024-05-08 14:05 Spencer Baugh 2024-05-10 1:57 ` Dmitry Gutov 0 siblings, 1 reply; 4+ messages in thread From: Spencer Baugh @ 2024-05-08 14:05 UTC (permalink / raw) To: 70833; +Cc: dmitry 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#70833: 29.2.50; project-current: allow control of the prompt string 2024-05-08 14:05 bug#70833: 29.2.50; project-current: allow control of the prompt string Spencer Baugh @ 2024-05-10 1:57 ` Dmitry Gutov 2024-10-04 14:06 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors 0 siblings, 1 reply; 4+ messages in thread From: Dmitry Gutov @ 2024-05-10 1:57 UTC (permalink / raw) To: Spencer Baugh, 70833 [-- 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))) ^ permalink raw reply related [flat|nested] 4+ messages in thread
* bug#70833: 29.2.50; project-current: allow control of the prompt string 2024-05-10 1:57 ` Dmitry Gutov @ 2024-10-04 14:06 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-10-07 23:13 ` Dmitry Gutov 0 siblings, 1 reply; 4+ messages in thread From: Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-04 14:06 UTC (permalink / raw) To: Dmitry Gutov; +Cc: 70833 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
* bug#70833: 29.2.50; project-current: allow control of the prompt string 2024-10-04 14:06 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2024-10-07 23:13 ` Dmitry Gutov 0 siblings, 0 replies; 4+ messages in thread From: Dmitry Gutov @ 2024-10-07 23:13 UTC (permalink / raw) To: Spencer Baugh; +Cc: 70833-done 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. ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2024-10-07 23:13 UTC | newest] Thread overview: 4+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2024-05-08 14:05 bug#70833: 29.2.50; project-current: allow control of the prompt string Spencer Baugh 2024-05-10 1:57 ` Dmitry Gutov 2024-10-04 14:06 ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors 2024-10-07 23:13 ` Dmitry Gutov
Code repositories for project(s) associated with this public 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 read-only IMAP folder(s) and NNTP newsgroup(s).