unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@janestreet.com>
To: 63870@debbugs.gnu.org
Subject: bug#63870: 29.0.90; project.el can't dynamically populate the project list
Date: Sat, 03 Jun 2023 07:55:10 -0400	[thread overview]
Message-ID: <ierjzwkahgh.fsf@janestreet.com> (raw)



project.el wants a list of known projects, for project-switch-project
and prompting in project-current.

Currently this list is maintained in two ways:
- automatically, by remembering any project the user runs project
  commands within
- manually by the user with project-remember-project and other functions

In both cases, this list is persisted so that it stays around through
Emacs restarts.  All this is good.

But, I often clone new repositories outside of Emacs, and I also have
scripts outside Emacs which make new clones automatically.  It would be
nice for project.el to know about those clones, so I can switch to them
with project-switch-project right away.  Instead, today I usually
manually navigate to those projects the first time, and I'm only able to
use project-switch-project on subsequent times.

These new repos are created in relatively predictable places, so I can
write code which discovers them all.  But I don't have a way to tell
project.el about them.

I could run code on a timer to project-remember-project these projects,
since I create them in predictable locations.  But that would mean
there's a delay between cloning the repo and being able to use it with
project-switch-project, which is annoying especially when I manually
cloned the repo and want to use it immediately.

The new projects are created while Emacs is running, so just remembering
them all at startup doesn't work either.

I'd like a customization point where I can supply a function (or list of
functions) which project-known-project-roots should run to produce an
additional list of project root directories, which should then be
appended to project--list.

I don't need project.el to specifically remember these projects; they'll
be remembered automatically as users use them, and completing-read will
nicely deduplicate the project roots anyway.

Does that seem reasonable?  It would be something like this:

diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el
index 04c67710d71..cc05cf460ef 100644
--- a/lisp/progmodes/project.el
+++ b/lisp/progmodes/project.el
@@ -1679,11 +1679,21 @@ project-prompt-project-name
       (let ((proj (assoc pr-name choices)))
         (if (stringp proj) proj (project-root (cdr proj)))))))
 
+(defcustom project-dynamic-roots '()
+  "List of functions to call to dynamically find projects.
+
+Each is called with no arguments and should return a list of
+project root dirs."
+  :type '(repeat function)
+  :group 'project
+  :version "30.1")
+
 ;;;###autoload
 (defun project-known-project-roots ()
   "Return the list of root directories of all known projects."
   (project--ensure-read-project-list)
-  (mapcar #'car project--list))
+  (flatten-tree (cons (mapcar #'car project--list)
+                      (mapcar #'funcall project-dynamic-roots))))
 
 ;;;###autoload
 (defun project-execute-extended-command ()





             reply	other threads:[~2023-06-03 11:55 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-03 11:55 Spencer Baugh [this message]
2023-06-15 19:30 ` bug#63870: 29.0.90; project.el can't dynamically populate the project list Spencer Baugh
2023-06-16  5:45   ` Eli Zaretskii
2023-06-17  2:55 ` Dmitry Gutov
2023-06-27 19:29   ` Spencer Baugh
2023-06-27 19:27 ` Spencer Baugh
2023-06-28 11:24   ` Eli Zaretskii
2023-06-28 12:05     ` Spencer Baugh
2023-06-28 12:18       ` Eli Zaretskii
2023-06-28 12:37         ` Spencer Baugh
2023-06-28 12:56           ` Eli Zaretskii
2023-07-18  2:21             ` Dmitry Gutov
2023-07-18 16:28               ` Spencer Baugh
2023-07-18 17:41                 ` Juri Linkov
2023-07-27  1:59                   ` Dmitry Gutov
2023-07-27  1:57                 ` 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=ierjzwkahgh.fsf@janestreet.com \
    --to=sbaugh@janestreet.com \
    --cc=63870@debbugs.gnu.org \
    /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).