unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Dmitry Gutov <dmitry@gutov.dev>
To: Spencer Baugh <sbaugh@janestreet.com>, 69584@debbugs.gnu.org
Subject: bug#69584: 29.2.50; project-find-functions should have access to maybe-prompt
Date: Fri, 15 Mar 2024 03:41:01 +0200	[thread overview]
Message-ID: <65b29bab-3149-49e3-a6ae-6c0c1485e6f2@gutov.dev> (raw)
In-Reply-To: <iero7brxwv7.fsf@janestreet.com>

Hi Spencer,

On 06/03/2024 16:23, Spencer Baugh wrote:
> 
> I'd like to write a project-find-function which might prompt when
> called, and so to suppress that prompting I'd like to be able to check
> the maybe-prompt argument that project-current received.

This is technically doable, but what looks worrying to me, is that this 
would make 'project-current' lose more of its idempotency.

Originally, the DIRECTORY argument for it was intended to make sure that 
all calls from the same directory would return the same instance. But of 
course a hook can be local, so some can find it practical to define 
buffer-local projects. This side-steps the original design, making, for 
example, the relation "files A and B are in the same project" not 
necessarily symmetric or transitive.

> Possible new functions for project-find-functions which would benefit
> from this:
> 
> - A local project-find-function in a version control buffer for viewing
> a branch log; if the branch is not currently checked out, prompt to
> check out that branch (or create a worktree for it) before returning the
> project
> 
> - A local project-find-function in a buffer from a package for Git
> forges; if the buffer corresponds to a repository which is not currently
> cloned locally, prompt to clone the repository.
> 
> These behaviors should of course be suppressed if maybe-prompt is nil,
> which is why it would be nice to be able to access maybe-prompt.

What would such project functions return when maybe-prompt is nil? Also 
nil, right? That would kind of create a separate category of projects, 
interactive-only.

With regards to caching, for example, if some caller wanted to do so 
(some related discussion: 
https://github.com/joaotavora/breadcrumb/issues/18#issuecomment-1984615275), 
then would also need to take this parameter into account.

So the first thing I'd ask is whether you see a different way to 
implement the same features. I don't see the whole usage scenarios, so 
it's hard to judge.

> Since adding a new argument to project-find-functions is hard, maybe we
> could do this by introducing a new dynamic variable
> project-find-functions-may-prompt which we let-bind?  Like:
> 
> diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
> index c7c07c3d34c..3975182b88d 100644
> --- a/lisp/progmodes/project.el
> +++ b/lisp/progmodes/project.el
> @@ -242,8 +242,9 @@ project-current
>           (setq pr (cons 'transient directory))))
>       pr))
>   
> -(defun project--find-in-directory (dir)
> -  (run-hook-with-args-until-success 'project-find-functions dir))
> +(defun project--find-in-directory (dir &optional maybe-prompt)
> +  (let ((project-find-functions-may-prompt maybe-prompt))
> +    (run-hook-with-args-until-success 'project-find-functions dir)))
>   
>   (defvar project--within-roots-fallback nil)

As far as the implementation goes, a dynamic variable can work. We could 
also try reusing an existing one: non-essential, and we'd set it to nil 
when maybe-prompt is non-nil.

I wonder how it would interact with Tramp (ask for password in 
disconnected buffers?), but that seems to fall into the same general 
category as your other cases.





  reply	other threads:[~2024-03-15  1:41 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-06 14:23 bug#69584: 29.2.50; project-find-functions should have access to maybe-prompt Spencer Baugh
2024-03-15  1:41 ` Dmitry Gutov [this message]
2024-03-16 13:31   ` sbaugh
2024-03-18 21:59     ` Dmitry Gutov
2024-03-22 13:05       ` Spencer Baugh
2024-03-28  3:44         ` Dmitry Gutov
2024-04-04 14:29           ` Spencer Baugh
2024-04-05  0:33             ` Dmitry Gutov
2024-09-23 20:16               ` Spencer Baugh via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-09-23 22:23                 ` Dmitry Gutov
2024-04-02 17:54         ` Spencer Baugh
2024-04-02 23:10           ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=65b29bab-3149-49e3-a6ae-6c0c1485e6f2@gutov.dev \
    --to=dmitry@gutov.dev \
    --cc=69584@debbugs.gnu.org \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).