From unknown Fri Jun 20 07:26:07 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#63870 <63870@debbugs.gnu.org> To: bug#63870 <63870@debbugs.gnu.org> Subject: Status: 29.0.90; project.el can't dynamically populate the project list Reply-To: bug#63870 <63870@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:26:07 +0000 retitle 63870 29.0.90; project.el can't dynamically populate the project li= st reassign 63870 emacs submitter 63870 Spencer Baugh severity 63870 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sat Jun 03 07:55:19 2023 Received: (at submit) by debbugs.gnu.org; 3 Jun 2023 11:55:19 +0000 Received: from localhost ([127.0.0.1]:41725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Pqo-0005iq-LE for submit@debbugs.gnu.org; Sat, 03 Jun 2023 07:55:19 -0400 Received: from lists.gnu.org ([209.51.188.17]:52728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q5Pqk-0005ib-4e for submit@debbugs.gnu.org; Sat, 03 Jun 2023 07:55:17 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Pqj-0006Nt-EX for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 07:55:13 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q5Pqh-0003xs-Nt for bug-gnu-emacs@gnu.org; Sat, 03 Jun 2023 07:55:13 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: 29.0.90; project.el can't dynamically populate the project list Date: Sat, 03 Jun 2023 07:55:10 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) 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 () From debbugs-submit-bounces@debbugs.gnu.org Thu Jun 15 15:30:58 2023 Received: (at 63870) by debbugs.gnu.org; 15 Jun 2023 19:30:58 +0000 Received: from localhost ([127.0.0.1]:47982 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9sgM-0000CW-4c for submit@debbugs.gnu.org; Thu, 15 Jun 2023 15:30:58 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:39389) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q9sgK-0000CI-0X for 63870@debbugs.gnu.org; Thu, 15 Jun 2023 15:30:57 -0400 From: Spencer Baugh To: 63870@debbugs.gnu.org Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 07:55:10 -0400") References: Date: Thu, 15 Jun 2023 15:30:50 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63870 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Actually I think a file-notify solution works great. I have one working for my use case and I'll post a patch for a generic one soon. From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 01:45:38 2023 Received: (at 63870) by debbugs.gnu.org; 16 Jun 2023 05:45:38 +0000 Received: from localhost ([127.0.0.1]:48463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2HC-0005eJ-05 for submit@debbugs.gnu.org; Fri, 16 Jun 2023 01:45:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59382) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qA2HA-0005Ms-DE for 63870@debbugs.gnu.org; Fri, 16 Jun 2023 01:45:36 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qA2H4-0005F0-1G; Fri, 16 Jun 2023 01:45:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NvcORpYdTL50ALzZ0gCR4rKc5JcgagI1azO0lkfdSRQ=; b=GiJKK2zM9hWw w+BMuFdf8eKkzp01ocB990ZGcHYjMaqWy1Q+VOY86vm0oXupPsmSQJzQoTuR8WBzNmUP5r02Eq1AJ zkIlyNNMOiTxS/o4mQD4BlSm3ufGyCsvSXINwLK4EDCh00hKb3CV2FknXPPyTt5GagV8rPBwnBHlE Qv+sl/oVjj/hZdCKtYo5MzkMUPdQYJZpZDT+bWSxpZfeq3KMHXgB2Z8+cu1NLs2h+EQbJ2MIsrm5s +BTPySQIZpGm5tmM1UYQ7EUGo3Yhg/OdqgpynZUNaZ/1gOXTKeXAD5tJWo+D1WNX92xsIBVcOcwd8 N1EMSe/gztx0U61/rOHeFQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qA2H1-0003pt-Aw; Fri, 16 Jun 2023 01:45:29 -0400 Date: Fri, 16 Jun 2023 08:45:52 +0300 Message-Id: <83a5x0t0xb.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Thu, 15 Jun 2023 15:30:50 -0400) Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Thu, 15 Jun 2023 15:30:50 -0400 > > Actually I think a file-notify solution works great. I have one working > for my use case and I'll post a patch for a generic one soon. Please keep in mind that in our experience watching a repository tree is problematic (if that is what you had in mind). From debbugs-submit-bounces@debbugs.gnu.org Fri Jun 16 22:56:10 2023 Received: (at 63870) by debbugs.gnu.org; 17 Jun 2023 02:56:11 +0000 Received: from localhost ([127.0.0.1]:50661 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAM6k-00053j-Kd for submit@debbugs.gnu.org; Fri, 16 Jun 2023 22:56:10 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:49291) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qAM6i-00053V-0e for 63870@debbugs.gnu.org; Fri, 16 Jun 2023 22:56:08 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 5212F320076F; Fri, 16 Jun 2023 22:56:02 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Fri, 16 Jun 2023 22:56:02 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :content-transfer-encoding:content-type:content-type:date:date :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm3; t= 1686970561; x=1687056961; bh=8UowMyp/s7QQW2MzyitU/E2/CLOYZkMsWVd JR0/8KyY=; b=G8ia4Qncz/vfBhdhYXdAnEjCLSOU8QV7Sx3FTolTZljUAHXx/uN 2ryrySyEd1qlO06RrnuUac8PtphdVv7tqKLZR7ci22ogTlyKxAaoNvbh7YE2qRez /IU8h1qcvvDq/agBb4Ksl3sJ0RVN3msBeCGAewSqScyi1S9HwLMeYmBurp7VsXlN pFxcFzId9DQxMlwspxNORcdG8NPtt1PuMc2ShnYozG82E2JTHeOgHu9bLYSicT61 OjwW9vMsUaV/FBEZgy73vyndT8yc/GHZTu8FXFi8I4KZcedMMSvze/LhwQhaLz28 X3jk5wUtByZais9DQAcg+TVnEJw5lzuTJoQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :content-type:date:date:feedback-id:feedback-id:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to:x-me-proxy:x-me-proxy :x-me-sender:x-me-sender:x-sasl-enc; s=fm2; t=1686970561; x= 1687056961; bh=8UowMyp/s7QQW2MzyitU/E2/CLOYZkMsWVdJR0/8KyY=; b=V 2bZXBIWMJQmH1WwRZXBcgniPRZlLNKLnmmfwnpqHDy7GifSapdB/FnrJHdREYSYU hFokmWTWlCDSFtWJlTQh4IY6SMWwVYRXUEezK01eYBqm8mKXOqIc0WUFS1HOARFf wDtV7q1Oz54liYTGE11KMaZ8HrjRpGFhPtqlGhEOdpOxKckIwdF9kzYLtG9Dq5wL Y4+nZD8sTAOOtrwr7C7DugPKDd2+RE08RJ759CIy1rblNMgX6xckWGDD/uIpG1kf j0Q/DpdLlAhpWB/9C2uS4BTMvl8D3cbG4rsYOeUD5/Xa2wAEwfPYUmT3m7a09c/W gSXY/wtXCSnyPA91eNgxg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrgedviedgvdeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhepkfffgggfuffvfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeghedthedujeeiteeutddtjeekheejteeukeehffdutdejuedvfeevueeviedu udenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Fri, 16 Jun 2023 22:56:00 -0400 (EDT) Message-ID: Date: Sat, 17 Jun 2023 05:55:59 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list Content-Language: en-US To: Spencer Baugh , 63870@debbugs.gnu.org References: From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 63870 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.9 (--) Hi! On 03/06/2023 14:55, Spencer Baugh wrote: > 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. Are you sure the existing functions won't cut it? Such as project-remember-project and project-forget-project. The names might seem a little wrong, but keeping in mind that project--list is about having a list of projects "remembered" somewhere, they're probably fine. And you could let-bind project--list somewhere at the top level in your function/command/etc, so the list is not altered in the end. > 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. We could add some var like project-list-no-write, so that dynamic changes don't get written to disk. Unless you want to keep the "dynamic" list to be used by regular commands, that is. In that case, the above will probably not suffice. We could go with your approach, or even add some project-list-sources hook. But how would the entries from different sources (e.g. the list file and your dynamic list) combined? How will they be sorted? In case we can't come up with a generic way, we could simply add a generic storage abstraction (similar to xref-history-storage), which you would override/advise to combine the lists as needed for your usage. From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 27 15:27:39 2023 Received: (at 63870) by debbugs.gnu.org; 27 Jun 2023 19:27:39 +0000 Received: from localhost ([127.0.0.1]:49551 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEELi-00019i-Sh for submit@debbugs.gnu.org; Tue, 27 Jun 2023 15:27:39 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:38145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEELg-00019S-Eo for 63870@debbugs.gnu.org; Tue, 27 Jun 2023 15:27:37 -0400 From: Spencer Baugh To: 63870@debbugs.gnu.org Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: (Spencer Baugh's message of "Sat, 03 Jun 2023 07:55:10 -0400") References: Date: Tue, 27 Jun 2023 15:27:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63870 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Add project-watch to discover projects with file-notify Projects can be created outside of Emacs, but users might want to be able to switch to them with project-switch-project immediately. This function supports that. If a user calls (project-watch "~/src" 1) then any projects under ~/src will be discovered automatically immediately after their creation. I have strived to make this function usable for a wide set of use-cases, I think it will be a useful addition to project.el. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Add-project-watch-to-discover-projects-with-file-not.patch >From b283eb7eec428b8b0027a28f8c5f547360386b80 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Tue, 27 Jun 2023 15:25:02 -0400 Subject: [PATCH] Add project-watch to discover projects with file-notify Projects can be created outside of Emacs, but users might want to be able to switch to them with project-switch-project immediately. This API supports that. If a user calls (project-watch "~/src" 1) then any projects under ~/src will be discovered automatically immediately after their creation. * lisp/progmodes/project.el (project-check-project) (project--watch-cb-children, project--watch-cb-this) (project--file-notify-watch, project-watch): Add. (bug#63870) --- lisp/progmodes/project.el | 51 +++++++++++++++++++++++++++++++++++++++ 1 file changed, 51 insertions(+) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 56c524bcab5..ddb033d50f9 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1884,5 +1884,56 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +(defun project-check-project (dir) + "If there's a project at DIR, remember it; otherwise, forget it. + +Return the found project, if any." + (let ((pr (project--find-in-directory dir))) + (if pr (project-remember-project pr) + (project-forget-project (file-name-as-directory dir))) + pr)) + +(defun project--watch-cb-children (recursive predicate event) + (unless (eq (cl-second event) 'stopped) + (dolist (file (cddr event)) + (condition-case _ (project-watch file recursive predicate) + ((file-error file-notify-error)))))) + +(defun project--watch-cb-this (dir event) + (unless (eq (cl-second event) 'stopped) + (when (project-check-project dir) + (file-notify-rm-watch (cl-first event))))) + +(defun project--file-notify-watch (dir callback &optional init) + "Like `file-notify-add-watch' but also calls CALLBACK immediately." + (let ((watch (file-notify-add-watch dir '(change) callback))) + (funcall callback (append (list watch 'started) init)))) + +;;;###autoload +(defun project-watch (dir &optional recursive predicate) + "Watch DIR until it becomes a project. + +We stop watching DIR once it becomes a project. + +If RECURSIVE is an integer greater than 0, we'll also run +`project-watch' on directories which appear inside DIR, +passing (1- RECURSIVE) as RECURSIVE. To achieve this, we'll +continue watching DIR even if it becomes a project. This can be +expensive, so it's better to pass small values of RECURSIVE, like +1 or 2. + +If PREDICATE is non-nil, it should be a function which will be +called with two arguments, the value of RECURSIVE and a +directory. Only directories for which PREDICATE returns non-nil +will be watched for being a project." + (setq predicate (or predicate (lambda (_recursive dir) t))) + (setq recursive (or recursive 0)) + (when (and (funcall predicate recursive dir) (file-directory-p dir)) + (project--file-notify-watch dir (apply-partially #'project--watch-cb-this dir))) + (when (> recursive 0) + (project--file-notify-watch + dir (apply-partially #'project--watch-cb-children (1- recursive) predicate) + (directory-files dir 'full directory-files-no-dot-files-regexp)))) + (provide 'project) ;;; project.el ends here -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jun 27 15:29:56 2023 Received: (at 63870) by debbugs.gnu.org; 27 Jun 2023 19:29:56 +0000 Received: from localhost ([127.0.0.1]:49561 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEENv-0001DN-Vt for submit@debbugs.gnu.org; Tue, 27 Jun 2023 15:29:56 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:34791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEENt-0001DA-V1 for 63870@debbugs.gnu.org; Tue, 27 Jun 2023 15:29:54 -0400 From: Spencer Baugh To: Dmitry Gutov Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: (Dmitry Gutov's message of "Sat, 17 Jun 2023 05:55:59 +0300") References: Date: Tue, 27 Jun 2023 15:29:48 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Hi! > > On 03/06/2023 14:55, Spencer Baugh wrote: >> 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. > > Are you sure the existing functions won't cut it? Such as > project-remember-project and project-forget-project. > > The names might seem a little wrong, but keeping in mind that > project--list is about having a list of projects "remembered" > somewhere, they're probably fine. And you could let-bind project--list > somewhere at the top level in your function/command/etc, so the list > is not altered in the end. Oh, certainly project-{remember,forget}-project work, indeed I've used them in the patch I just posted. I think I was unclear about what I wanted, perhaps that patch clarifies what exactly I was looking for. >> 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. > > We could add some var like project-list-no-write, so that dynamic > changes don't get written to disk. > > Unless you want to keep the "dynamic" list to be used by regular > commands, that is. > > In that case, the above will probably not suffice. We could go with > your approach, or even add some project-list-sources hook. > > But how would the entries from different sources (e.g. the list file > and your dynamic list) combined? How will they be sorted? > > In case we can't come up with a generic way, we could simply add a > generic storage abstraction (similar to xref-history-storage), which > you would override/advise to combine the lists as needed for your > usage. I don't think these changes are necessary after all. (Which is good, because they would add a fair bit of complexity.) This file-notify approach I think should work perfectly for a wide variety of uses. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 28 07:24:31 2023 Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 11:24:31 +0000 Received: from localhost ([127.0.0.1]:50120 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qETHi-0001Ex-SK for submit@debbugs.gnu.org; Wed, 28 Jun 2023 07:24:31 -0400 Received: from eggs.gnu.org ([209.51.188.92]:45950) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qETHf-0001Ee-2j for 63870@debbugs.gnu.org; Wed, 28 Jun 2023 07:24:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qETHZ-0001qJ-KN; Wed, 28 Jun 2023 07:24:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=EXNf5VCMr6JhSIN4ETYi2vWwzYX91VuHPxlChNFsVXc=; b=YQaDwqnGM0b3 ijpAPiyNL9DUBdf7hI4b91hdS3OxnJ/IiynelevMg7jz7NcmRxLuUCNRkiWMqjnHoNROksobjWxnX SELca+nvleO1LsCh0OZ470yIRGMnOVyQPGHr2kS745QdsfOJ0jvRo46U4w5HOzRVP34nhjKNLablI Qom4v0iYYPVKAb6J/hW2ghbHYS6/YpSycMbGfi6nyPgBneBeftuA29Ybt8R4XS31hzV216BUx0oSu VOBT2FrlL1LjgfAccJWz/eBPNim+5Mdf6tUp+73cvtsSFw+YrmeIDh973Bzus4oQi2yUDpVrUrN/9 2thcVmLy5ge9g0j8QftTGw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qETHZ-00026E-4M; Wed, 28 Jun 2023 07:24:21 -0400 Date: Wed, 28 Jun 2023 14:24:46 +0300 Message-Id: <83sfabvngh.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Tue, 27 Jun 2023 15:27:30 -0400) Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Tue, 27 Jun 2023 15:27:30 -0400 > > +(defun project-check-project (dir) > + "If there's a project at DIR, remember it; otherwise, forget it. > + > +Return the found project, if any." > + (let ((pr (project--find-in-directory dir))) > + (if pr (project-remember-project pr) > + (project-forget-project (file-name-as-directory dir))) > + pr)) > + > +(defun project--watch-cb-children (recursive predicate event) > + (unless (eq (cl-second event) 'stopped) > + (dolist (file (cddr event)) > + (condition-case _ (project-watch file recursive predicate) > + ((file-error file-notify-error)))))) > + > +(defun project--watch-cb-this (dir event) > + (unless (eq (cl-second event) 'stopped) > + (when (project-check-project dir) > + (file-notify-rm-watch (cl-first event))))) > + > +(defun project--file-notify-watch (dir callback &optional init) > + "Like `file-notify-add-watch' but also calls CALLBACK immediately." > + (let ((watch (file-notify-add-watch dir '(change) callback))) > + (funcall callback (append (list watch 'started) init)))) Beware of watching a tree recursively: file notifications are not very scalable, for more than one reason. For example, the inotify backend consumes a file descriptor and a slot in the descriptor set monitored by pselect per each file/directory you watch. And watching many directories can overwhelm Emacs if some program (even unrelated to Emacs) performs many file operations in that directory; VCS programs are notorious in this regard, e.g., when you update from upstream. > +(defun project-watch (dir &optional recursive predicate) > + "Watch DIR until it becomes a project. > + > +We stop watching DIR once it becomes a project. This never explains what it means for a directory to "become a project". It should, because this doc string begs that question. > +If RECURSIVE is an integer greater than 0, we'll also run > +`project-watch' on directories which appear inside DIR, > +passing (1- RECURSIVE) as RECURSIVE. To achieve this, we'll > +continue watching DIR even if it becomes a project. This can be > +expensive, so it's better to pass small values of RECURSIVE, like > +1 or 2. Are you sure this feature justifies the risks? When would someone want to use it, while simultaneously limiting the value of RECURSIVE to some small integer? (And what is considered "small" for these purposes?) Thanks. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 28 08:05:33 2023 Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 12:05:33 +0000 Received: from localhost ([127.0.0.1]:50208 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qETvR-0004uE-3F for submit@debbugs.gnu.org; Wed, 28 Jun 2023 08:05:33 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:58467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qETvM-0004ts-Kx for 63870@debbugs.gnu.org; Wed, 28 Jun 2023 08:05:31 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: <83sfabvngh.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 28 Jun 2023 14:24:46 +0300") References: <83sfabvngh.fsf@gnu.org> Date: Wed, 28 Jun 2023 08:05:23 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Date: Tue, 27 Jun 2023 15:27:30 -0400 >> >> +(defun project-check-project (dir) >> + "If there's a project at DIR, remember it; otherwise, forget it. >> + >> +Return the found project, if any." >> + (let ((pr (project--find-in-directory dir))) >> + (if pr (project-remember-project pr) >> + (project-forget-project (file-name-as-directory dir))) >> + pr)) >> + >> +(defun project--watch-cb-children (recursive predicate event) >> + (unless (eq (cl-second event) 'stopped) >> + (dolist (file (cddr event)) >> + (condition-case _ (project-watch file recursive predicate) >> + ((file-error file-notify-error)))))) >> + >> +(defun project--watch-cb-this (dir event) >> + (unless (eq (cl-second event) 'stopped) >> + (when (project-check-project dir) >> + (file-notify-rm-watch (cl-first event))))) >> + >> +(defun project--file-notify-watch (dir callback &optional init) >> + "Like `file-notify-add-watch' but also calls CALLBACK immediately." >> + (let ((watch (file-notify-add-watch dir '(change) callback))) >> + (funcall callback (append (list watch 'started) init)))) > > Beware of watching a tree recursively: file notifications are not very > scalable, for more than one reason. For example, the inotify backend > consumes a file descriptor and a slot in the descriptor set monitored > by pselect per each file/directory you watch. And watching many > directories can overwhelm Emacs if some program (even unrelated to > Emacs) performs many file operations in that directory; VCS programs > are notorious in this regard, e.g., when you update from upstream. Absolutely. I am trying to be careful about this: project-watch shouldn't create watches on VCS directories. >> +(defun project-watch (dir &optional recursive predicate) >> + "Watch DIR until it becomes a project. >> + >> +We stop watching DIR once it becomes a project. > > This never explains what it means for a directory to "become a > project". It should, because this doc string begs that question. A directory "becomes a project" once some function on project-find-functions returns non-nil for it. I'll include this in the docstring of the next version of the patch. >> +If RECURSIVE is an integer greater than 0, we'll also run >> +`project-watch' on directories which appear inside DIR, >> +passing (1- RECURSIVE) as RECURSIVE. To achieve this, we'll >> +continue watching DIR even if it becomes a project. This can be >> +expensive, so it's better to pass small values of RECURSIVE, like >> +1 or 2. > > Are you sure this feature justifies the risks? When would someone > want to use it, while simultaneously limiting the value of RECURSIVE > to some small integer? (And what is considered "small" for these > purposes?) Imagine, for example, that a user has a directory ~/src. They make all their VCS clones directly under ~/src: ~/src/emacs, ~/src/glibc, etc. And when they work on a new project, they create that new clone under ~/src. If the user wanted all these VCS clones to show up in Emacs as soon as they're made, they could run (project-watch "~/src" 1). This would create a watch on ~/src, which would create watches on new empty directories under ~/src (e.g. ~/src/gdb); the watch on ~/src/gdb would stop if and when ~/src/gdb becomes a project (as defined above). So in the steady state, if ~/src contains only projects, Emacs would run exactly one watch, the one on ~/src. This is definitely okay. If, instead, ~/src has a two-level structure, where ~/src/emacs is not itself a clone but instead contains a clone for each branch, e.g. ~/src/emacs/emacs-29 and ~/src/emacs/trunk, then a user might run (project-watch "~/src" 2). Then in the steady state there would be one watch on ~/src and one watch on each subdirectory of ~/src, e.g. ~/src/emacs. (This is the setup I personally have.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 28 08:18:47 2023 Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 12:18:47 +0000 Received: from localhost ([127.0.0.1]:50220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEU8E-0005FP-St for submit@debbugs.gnu.org; Wed, 28 Jun 2023 08:18:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:55866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEU8A-0005FB-RH for 63870@debbugs.gnu.org; Wed, 28 Jun 2023 08:18:45 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qEU82-0008Ie-AG; Wed, 28 Jun 2023 08:18:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fy0cZwEDLaZFCwO/bsXeq2Fm7vxPH74xepucUiw+JxQ=; b=ehaU4+bx4GEd kNvJDVBwrNJV21w7dFraSlcixEEYroTiZ89EQCaHxcrKi9V1cMWfu/WuBVlYSkoy2ojhLQ/E2CmF4 +lNQccrMdaXY1PBd/w+r8n1vCqbE6eb0XJ+sUdiqxzlyamw6BcOPJYWXwMwOz02UwcVbEV0DS/DMg FpZeiVvcSpHMboUGPsDEqMkorFCa8wtUWhN3OB27029FgkvKpDGOzFvsG07Q40O24Q62ryXqzzqj5 NoiMC2RBgUNKv9wEvR8GKsKqv1KYbwDOXq5hhAcYr3AArVy74TZuwqqz6f6ZEV8oA7XuFSBPI4Cip A3pvPmH1SIUG8VQ/w6izeQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qEU81-0006vV-HQ; Wed, 28 Jun 2023 08:18:34 -0400 Date: Wed, 28 Jun 2023 15:18:59 +0300 Message-Id: <83edlvvky4.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 28 Jun 2023 08:05:23 -0400) Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list References: <83sfabvngh.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: 63870@debbugs.gnu.org > Date: Wed, 28 Jun 2023 08:05:23 -0400 > > Eli Zaretskii writes: > > > Beware of watching a tree recursively: file notifications are not very > > scalable, for more than one reason. For example, the inotify backend > > consumes a file descriptor and a slot in the descriptor set monitored > > by pselect per each file/directory you watch. And watching many > > directories can overwhelm Emacs if some program (even unrelated to > > Emacs) performs many file operations in that directory; VCS programs > > are notorious in this regard, e.g., when you update from upstream. > > Absolutely. I am trying to be careful about this: project-watch > shouldn't create watches on VCS directories. But below you explicitly give an example where it will. And given the fact that the majority of project.el projects use VCS as its backend, I'd say we are already there... > > Are you sure this feature justifies the risks? When would someone > > want to use it, while simultaneously limiting the value of RECURSIVE > > to some small integer? (And what is considered "small" for these > > purposes?) > > Imagine, for example, that a user has a directory ~/src. They make all > their VCS clones directly under ~/src: ~/src/emacs, ~/src/glibc, etc. > And when they work on a new project, they create that new clone under > ~/src. > > If the user wanted all these VCS clones to show up in Emacs as soon as > they're made, they could run (project-watch "~/src" 1). This would > create a watch on ~/src, which would create watches on new empty > directories under ~/src (e.g. ~/src/gdb); the watch on ~/src/gdb would > stop if and when ~/src/gdb becomes a project (as defined above). > > So in the steady state, if ~/src contains only projects, Emacs would run > exactly one watch, the one on ~/src. This is definitely okay. > > If, instead, ~/src has a two-level structure, where ~/src/emacs is not > itself a clone but instead contains a clone for each branch, > e.g. ~/src/emacs/emacs-29 and ~/src/emacs/trunk, then a user might run > (project-watch "~/src" 2). Then in the steady state there would be one > watch on ~/src and one watch on each subdirectory of ~/src, > e.g. ~/src/emacs. (This is the setup I personally have.) If you want to support one or two levels of recursion, let's support just that and remove the too-general RECURSIVE argument. If you think there might be important use cases where there's more than one or two levels of recursion, please describe them. Once again, this is dangerous; users could easily shoot themselves in the foot, because not many are aware of the pitfall of using file notifications for many directories. It makes no sense to warn against something and at the same time let callers easily stumble upon that. From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 28 08:38:06 2023 Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 12:38:06 +0000 Received: from localhost ([127.0.0.1]:50240 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEUQv-0005jL-Ss for submit@debbugs.gnu.org; Wed, 28 Jun 2023 08:38:06 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:54261) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEUQu-0005is-0n for 63870@debbugs.gnu.org; Wed, 28 Jun 2023 08:38:04 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: <83edlvvky4.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 28 Jun 2023 15:18:59 +0300") References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> Date: Wed, 28 Jun 2023 08:37:58 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: 63870@debbugs.gnu.org >> Date: Wed, 28 Jun 2023 08:05:23 -0400 >> >> Eli Zaretskii writes: >> >> > Beware of watching a tree recursively: file notifications are not very >> > scalable, for more than one reason. For example, the inotify backend >> > consumes a file descriptor and a slot in the descriptor set monitored >> > by pselect per each file/directory you watch. And watching many >> > directories can overwhelm Emacs if some program (even unrelated to >> > Emacs) performs many file operations in that directory; VCS programs >> > are notorious in this regard, e.g., when you update from upstream. >> >> Absolutely. I am trying to be careful about this: project-watch >> shouldn't create watches on VCS directories. > > But below you explicitly give an example where it will. And given the > fact that the majority of project.el projects use VCS as its backend, > I'd say we are already there... No: the watch on a directory is removed once the directory becomes a VCS directory. >> > Are you sure this feature justifies the risks? When would someone >> > want to use it, while simultaneously limiting the value of RECURSIVE >> > to some small integer? (And what is considered "small" for these >> > purposes?) >> >> Imagine, for example, that a user has a directory ~/src. They make all >> their VCS clones directly under ~/src: ~/src/emacs, ~/src/glibc, etc. >> And when they work on a new project, they create that new clone under >> ~/src. >> >> If the user wanted all these VCS clones to show up in Emacs as soon as >> they're made, they could run (project-watch "~/src" 1). This would >> create a watch on ~/src, which would create watches on new empty >> directories under ~/src (e.g. ~/src/gdb); the watch on ~/src/gdb would >> stop if and when ~/src/gdb becomes a project (as defined above). >> >> So in the steady state, if ~/src contains only projects, Emacs would run >> exactly one watch, the one on ~/src. This is definitely okay. >> >> If, instead, ~/src has a two-level structure, where ~/src/emacs is not >> itself a clone but instead contains a clone for each branch, >> e.g. ~/src/emacs/emacs-29 and ~/src/emacs/trunk, then a user might run >> (project-watch "~/src" 2). Then in the steady state there would be one >> watch on ~/src and one watch on each subdirectory of ~/src, >> e.g. ~/src/emacs. (This is the setup I personally have.) > > If you want to support one or two levels of recursion, let's support > just that and remove the too-general RECURSIVE argument. If you think > there might be important use cases where there's more than one or two > levels of recursion, please describe them. Hm, well, I assume some users might use even more structure than this; for example, some might have ~/src/gnu/emacs/emacs-29. Then they'd want 3 levels of recursion. > Once again, this is dangerous; users could easily shoot themselves in > the foot, because not many are aware of the pitfall of using file > notifications for many directories. It makes no sense to warn against > something and at the same time let callers easily stumble upon that. I agree with that, I suppose. Personally I would be fine with a mandatory 1 or 2 levels of recursion, since I only need 2. Do you have a suggestion for what that interface could look like? It feels a bit awkward... From debbugs-submit-bounces@debbugs.gnu.org Wed Jun 28 08:56:20 2023 Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 12:56:20 +0000 Received: from localhost ([127.0.0.1]:50271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEUiZ-0006FV-LN for submit@debbugs.gnu.org; Wed, 28 Jun 2023 08:56:20 -0400 Received: from eggs.gnu.org ([209.51.188.92]:56334) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qEUiX-0006FH-Iv for 63870@debbugs.gnu.org; Wed, 28 Jun 2023 08:56:18 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qEUiS-0002OC-6c; Wed, 28 Jun 2023 08:56:12 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=k4m6g10CxU1kQ4AHPM0T5axmYWCAi5wA1fcNMUnusDM=; b=o5n+AEI1zRob lLVq6Pg+85dehCulPUSw6Ja7AIsz07nm5e8jWcc/XPLRoYNIZ+1bimdgpX3lsv8nBD5dxonQ1xyFs Eu1BI+JhXFj+LZiA9ByV7Eg0QpGIssF5ptjs15MJ4WMMWtXqTwtiapk85yBEGBR00FSTXf8m5agtU YV8gJIMPiWuJ+k3yR5bAVC/F03JYnK+558W1d0Rn/AdqdBf2X49CHkJs3xnx4yOgh8cyTqxHl5h/y YNQcQtWymbLoUPWEcqAXU0VakYEzyi4LJzF1vGvkJPE2CB+M3Smnif5CZP+JN37kdHWcrVRIpWJxb GGpF4Aubg5QAtc+rX/yqqQ==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qEUiP-000788-G3; Wed, 28 Jun 2023 08:56:11 -0400 Date: Wed, 28 Jun 2023 15:56:34 +0300 Message-Id: <83bkgzvj7h.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 28 Jun 2023 08:37:58 -0400) Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: 63870@debbugs.gnu.org > Date: Wed, 28 Jun 2023 08:37:58 -0400 > > Eli Zaretskii writes: > > >> Absolutely. I am trying to be careful about this: project-watch > >> shouldn't create watches on VCS directories. > > > > But below you explicitly give an example where it will. And given the > > fact that the majority of project.el projects use VCS as its backend, > > I'd say we are already there... > > No: the watch on a directory is removed once the directory becomes a VCS > directory. No, AFAIU the watch is removed once there is a project in the directory. But a VCS can work on a directory regardles of any project creation. > > Once again, this is dangerous; users could easily shoot themselves in > > the foot, because not many are aware of the pitfall of using file > > notifications for many directories. It makes no sense to warn against > > something and at the same time let callers easily stumble upon that. > > I agree with that, I suppose. Personally I would be fine with a > mandatory 1 or 2 levels of recursion, since I only need 2. Do you have > a suggestion for what that interface could look like? It feels a bit > awkward... I'd actually begin by not providing even 1 level. Let the callers call this new function explicitly for every directory which they want watching. If someone ever complains that this is somehow inconvenient (although I don't see why: directory-files is simple to use), then we could consider extending the API. But that's MO; please wait for Dmitry to chime in. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 17 22:21:52 2023 Received: (at 63870) by debbugs.gnu.org; 18 Jul 2023 02:21:52 +0000 Received: from localhost ([127.0.0.1]:51282 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLaLX-0008Mx-QN for submit@debbugs.gnu.org; Mon, 17 Jul 2023 22:21:52 -0400 Received: from wout1-smtp.messagingengine.com ([64.147.123.24]:53937) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLaLT-0008Mi-7f for 63870@debbugs.gnu.org; Mon, 17 Jul 2023 22:21:50 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 4443F32008FA; Mon, 17 Jul 2023 22:21:41 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 17 Jul 2023 22:21:41 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689646900; x=1689733300; bh=r1kYPHABQYby2zZ09htTYA28TsEnfNkQPuf 1za4MoDY=; b=g9wcaj2rta6o3n9tJOTZZtMIFT0VVwlfw/AEfVxc8KOE5wltXkZ naPcRZSZIwArTN8STp28L1qquN8XDtP0PM/HpZznU4fU7MDGszLYap93MYIW9U4g JP2WuAsR9o8ZXGohXJfQ4BUbhVB3BLDqgahl9WG33VkHLeA2nnxTVAs5Z8SA69LL 7YuRGoq+4W+zC8LHz2ixXwQG0twoun2ndjcdzIrKkj67v26o7NQrldA3P6Vysyyv UCpPv+VelXJtQPWeJ9YKd1SA+/uA3I/SJAuXUwYpT9bZyBgTTXRHCdR+swGeayV1 vfrvMABevLSBqDAXiC0xztBwwXS5T/U0/VQ== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689646900; x=1689733300; bh=r1kYPHABQYby2zZ09htTYA28TsEnfNkQPuf 1za4MoDY=; b=hkslP4RdzoA90223mi6VRsB80OMYgPfODYaT9eY3YNBP71LWVg6 987zHmmm/RejeVoh/WQ++36mbNdHnU2wVYhcAi3UEACOF57yl34aHqG+z27V/huU /eLUKAKJt3kybt0Yy5vqctUbkUw3U1TsRCDq6Tc5VJgqQaYl4z/zmOwzI9COPe2t VVp23/FQDt5tVOxslUuf1dn5p/lRYPC43UqVOARcogBIIOKX2PVi82Q86AlXT42S xLnVrJn58FCDykqBrFrPcxIM2AXoRrW/HvPIJQt2ebfC8WkohroM626fb0Uf3mI5 xc8DbA8zBxIlH7/QfoTVHdGTydgtyoQvaRQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeefgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jul 2023 22:21:39 -0400 (EDT) Message-ID: <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> Date: Tue, 18 Jul 2023 05:21:37 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list Content-Language: en-US To: Eli Zaretskii , Spencer Baugh References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83bkgzvj7h.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 63870 Cc: 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 28/06/2023 15:56, Eli Zaretskii wrote: >>> Once again, this is dangerous; users could easily shoot themselves in >>> the foot, because not many are aware of the pitfall of using file >>> notifications for many directories. It makes no sense to warn against >>> something and at the same time let callers easily stumble upon that. >> I agree with that, I suppose. Personally I would be fine with a >> mandatory 1 or 2 levels of recursion, since I only need 2. Do you have >> a suggestion for what that interface could look like? It feels a bit >> awkward... > I'd actually begin by not providing even 1 level. Let the callers > call this new function explicitly for every directory which they want > watching. If someone ever complains that this is somehow inconvenient > (although I don't see why: directory-files is simple to use), then we > could consider extending the API. That sounds about right. But I might go a little further in this reasoning... (*) > But that's MO; please wait for Dmitry to chime in. [ Sorry for the late response, I'm still uncertain about this patch. ] (*) ... and ask whether this functionality makes sense built-in. I appreciate that it's succinct, documented and doesn't take a lot of space. But would we say that it covers a significantly general use case? Do we know many other developers who would appreciate it? Do a lot of devs at Jane Street use Emacs and this same workflow? Should we ask people somewhere (emacs-devel/Reddit/etc) whether they will find it useful? If it's just for one user at this point, then it shouldn't be difficult to maintain this code inside the init dir. Here's also some alternative I could potentially suggest: if you have some code which checks out new branches for development, or projects to start work on, and it's written in Elisp too, could it just call project-remember-project at the end? That would circumvent the need for using file watches altogether. Or if we do add this to project.el, we should try to make it safe for an average user even with a different directory structure. Suppose they have a dir D which they call project-watch on, and then they copy a big non-project directory inside. That should trigger many filenotify events, and since no search would result in success, I suppose the watch stays on, and every directory gets scanned up until the root. So an easy-to-enable recursive behavior seems dangerous for this case. Needless to say, the user could call this function, spend time on other stuff, forget, and then get surprised by things taking longer than expected. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 12:28:51 2023 Received: (at 63870) by debbugs.gnu.org; 18 Jul 2023 16:28:51 +0000 Received: from localhost ([127.0.0.1]:54078 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLnZD-0001BL-0Y for submit@debbugs.gnu.org; Tue, 18 Jul 2023 12:28:51 -0400 Received: from mxout6.mail.janestreet.com ([64.215.233.21]:50497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLnZ8-0001B3-3m for 63870@debbugs.gnu.org; Tue, 18 Jul 2023 12:28:50 -0400 From: Spencer Baugh To: Dmitry Gutov Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> (Dmitry Gutov's message of "Tue, 18 Jul 2023 05:21:37 +0300") References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> Date: Tue, 18 Jul 2023 12:28:40 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 63870 Cc: Eli Zaretskii , 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 28/06/2023 15:56, Eli Zaretskii wrote: >>>> Once again, this is dangerous; users could easily shoot themselves in >>>> the foot, because not many are aware of the pitfall of using file >>>> notifications for many directories. It makes no sense to warn against >>>> something and at the same time let callers easily stumble upon that. >>> I agree with that, I suppose. Personally I would be fine with a >>> mandatory 1 or 2 levels of recursion, since I only need 2. Do you have >>> a suggestion for what that interface could look like? It feels a bit >>> awkward... >> I'd actually begin by not providing even 1 level. Let the callers >> call this new function explicitly for every directory which they want >> watching. If someone ever complains that this is somehow inconvenient >> (although I don't see why: directory-files is simple to use), then we >> could consider extending the API. > > That sounds about right. But I might go a little further in this > reasoning... (*) > >> But that's MO; please wait for Dmitry to chime in. > > [ Sorry for the late response, I'm still uncertain about this patch. ] > > (*) ... and ask whether this functionality makes sense built-in. > > I appreciate that it's succinct, documented and doesn't take a lot of > space. But would we say that it covers a significantly general use > case? Do we know many other developers who would appreciate it? Do a > lot of devs at Jane Street use Emacs and this same workflow? Should we > ask people somewhere (emacs-devel/Reddit/etc) whether they will find > it useful? It's something we'd use a lot, but I have no problem keeping it locally for now. I agree it has some dangers, maybe I'll come up with a good way to make it safe for the casual user. > If it's just for one user at this point, then it shouldn't be > difficult to maintain this code inside the init dir. > > Here's also some alternative I could potentially suggest: if you have > some code which checks out new branches for development, or projects > to start work on, and it's written in Elisp too, could it just call > project-remember-project at the end? That would circumvent the need > for using file watches altogether. That works great for stuff written in Elisp too, but alas, there are command line tools to check out branches for development, etc, and I want them to update Emacs too. > Or if we do add this to project.el, we should try to make it safe for > an average user even with a different directory structure. Suppose > they have a dir D which they call project-watch on, and then they copy > a big non-project directory inside. That should trigger many > filenotify events, and since no search would result in success, I > suppose the watch stays on, and every directory gets scanned up until > the root. So an easy-to-enable recursive behavior seems dangerous for > this case. > > Needless to say, the user could call this function, spend time on > other stuff, forget, and then get surprised by things taking longer > than expected. Definitely. I'll think about whether there's a way to avoid such footguns... (Maybe I'll revisit this after writing some scripts like this for Emacs development - although those will definitely only be in Elisp, so it would be kind of moot) From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 13:42:52 2023 Received: (at 63870) by debbugs.gnu.org; 18 Jul 2023 17:42:53 +0000 Received: from localhost ([127.0.0.1]:54197 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLoin-0005hU-J7 for submit@debbugs.gnu.org; Tue, 18 Jul 2023 13:42:52 -0400 Received: from relay9-d.mail.gandi.net ([217.70.183.199]:33443) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLoik-0005hG-U8 for 63870@debbugs.gnu.org; Tue, 18 Jul 2023 13:42:48 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id CF0EBFF807; Tue, 18 Jul 2023 17:42:39 +0000 (UTC) From: Juri Linkov To: Spencer Baugh Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list In-Reply-To: (Spencer Baugh's message of "Tue, 18 Jul 2023 12:28:40 -0400") Organization: LINKOV.NET References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> Date: Tue, 18 Jul 2023 20:41:56 +0300 Message-ID: <864jm186cb.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 63870 Cc: Dmitry Gutov , Eli Zaretskii , 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > (Maybe I'll revisit this after writing some scripts like this for Emacs > development - although those will definitely only be in Elisp, so it > would be kind of moot) Why can't project--ensure-read-project-list scan a list of known roots to find a new project? I.e. the reverse of project-forget-projects-under. Or like there is an item "... (choose a dir)", another item could be "*Rescan*" that will try to find a new project under known roots. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 26 21:57:26 2023 Received: (at 63870) by debbugs.gnu.org; 27 Jul 2023 01:57:26 +0000 Received: from localhost ([127.0.0.1]:40414 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOqFq-00089P-8D for submit@debbugs.gnu.org; Wed, 26 Jul 2023 21:57:26 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:44637) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOqFo-00089C-7Y for 63870@debbugs.gnu.org; Wed, 26 Jul 2023 21:57:24 -0400 Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.west.internal (Postfix) with ESMTP id 7AE583200313; Wed, 26 Jul 2023 21:57:18 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Wed, 26 Jul 2023 21:57:18 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1690423037; x=1690509437; bh=qIyx6Hp3w7gJr+vaBl/2BB/M8MpLu97sKZc SCDGN5vg=; b=AiB17z+fCka5hisaNZGKlYwnT3YuSfrtwoRE+GiOcNCD6vWcYXH ymK9bodHph+37aTyoKtDr6kfYIVYLh6fWCeuCrbmrrJfcb8AvF9FuT6gkYE8rVO2 o3e123tT6UwwQm9xHHkLNROXrQrar7KpIqPhBVht4LhDOuSU86bLoplhXz43Ei7D SnlHrDzAB92LjIG3kG0fufzJruIhlyIukabURK0kVvvSW2wvTib5As6NYHzV+4Sr e6XKphMJ9qg6ZVo5GVmvBCCqUYCMmMlBnUS+5pfHW7lU8EH8nj+V+/IofHvoEQHQ LEd5/F6dNzS8ItYbS1ooEc2y/6JOjafRghA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1690423037; x=1690509437; bh=qIyx6Hp3w7gJr+vaBl/2BB/M8MpLu97sKZc SCDGN5vg=; b=TLWtgc1qEYnFLKMkTReB/2vlRearPh1JFgDqR/YlC/KBRXiwNOo tXifILgsVkb5sq3P0xNEatM1yglkKGIXJTYPoOb0oRnLQhBpyelOuQYhrgT6PDvg 7pzXkB8kGgQWb22W/esVJ1XwTwe7QzhatCp4DebgLbjpqguP7ZVEYgpS4yGEvKN+ TSyKHVlLhra3R94qKc5Uqs9s1SgsPj4wGJObAqDDBXk6eD97GMg98Tcn5gFkPBB+ WS3hlypfmbcpMl5Y/n2RuN0DkVdeathdlx8fVcxr8GpoKtDEHW8Ku4hHuvD3Qcyp ohiCuk10nAPfsvsDmFlhvxSi+tSH8uh6o8Q== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrieefgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Jul 2023 21:57:16 -0400 (EDT) Message-ID: <9561ede9-1699-8d9f-28ac-50fbba66b8ac@gutov.dev> Date: Thu, 27 Jul 2023 04:57:15 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list Content-Language: en-US To: Spencer Baugh References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 63870 Cc: Eli Zaretskii , 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 18/07/2023 19:28, Spencer Baugh wrote: >>> But that's MO; please wait for Dmitry to chime in. >> >> [ Sorry for the late response, I'm still uncertain about this patch. ] >> >> (*) ... and ask whether this functionality makes sense built-in. >> >> I appreciate that it's succinct, documented and doesn't take a lot of >> space. But would we say that it covers a significantly general use >> case? Do we know many other developers who would appreciate it? Do a >> lot of devs at Jane Street use Emacs and this same workflow? Should we >> ask people somewhere (emacs-devel/Reddit/etc) whether they will find >> it useful? > > It's something we'd use a lot, but I have no problem keeping it locally > for now. I agree it has some dangers, maybe I'll come up with a good > way to make it safe for the casual user. Thank you. >> If it's just for one user at this point, then it shouldn't be >> difficult to maintain this code inside the init dir. >> >> Here's also some alternative I could potentially suggest: if you have >> some code which checks out new branches for development, or projects >> to start work on, and it's written in Elisp too, could it just call >> project-remember-project at the end? That would circumvent the need >> for using file watches altogether. > > That works great for stuff written in Elisp too, but alas, there are > command line tools to check out branches for development, etc, and I > want them to update Emacs too. Just something to consider: you could invoke those shell scripts from Emacs Lisp, and then they finish, the Lisp program could do some additional steps, like adding projects to the list. Or removing -- in the reverse case. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 26 21:59:44 2023 Received: (at 63870) by debbugs.gnu.org; 27 Jul 2023 01:59:44 +0000 Received: from localhost ([127.0.0.1]:40419 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOqI3-0008Cg-QM for submit@debbugs.gnu.org; Wed, 26 Jul 2023 21:59:44 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:44127) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOqI1-0008CR-7F for 63870@debbugs.gnu.org; Wed, 26 Jul 2023 21:59:42 -0400 Received: from compute6.internal (compute6.nyi.internal [10.202.2.47]) by mailout.west.internal (Postfix) with ESMTP id EC0CA3200913; Wed, 26 Jul 2023 21:59:34 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute6.internal (MEProxy); Wed, 26 Jul 2023 21:59:35 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm2; t= 1690423174; x=1690509574; bh=sDoTFXhFlUuVX5KF7U/YfZUuz2oDVaiPLsA 4s03rpnY=; b=pH9P9UWSwQps4kE/s6xsLUW5GHZ6tm+CA04a4KFAprUm5TPDYGG KTH8VlFLboyZI3bBjiPk4slTSrSlDVlDKoOZ4B1GLcDsYT1TFp35KbzVlmpVFgCj MF+27A6rg4DcfhQDylDAKiYbVSUTyjZ58a25M3+OTa0Q4UiQzkRH8ezlD/5Eu2y4 +M6xiTfXCLxLPcbDDo8JJk2m8CtoQOXVYmzBxf5P3eAkc4srTw9Nd0UnJ2V4nWOE 6Q0aAxu8xArHIMmsizojySKS6Y0TD7dT2NUNCiteJ/PpcVC0+Sr3GNt+1hDMGEbM ZK/BrlCiQfIZCwhxDRkKZ2WFs/vcTEeO96A== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1690423174; x=1690509574; bh=sDoTFXhFlUuVX5KF7U/YfZUuz2oDVaiPLsA 4s03rpnY=; b=kPTAdqHkm0FlVyBYNc4vIunkCddV2Iddbb8qzdasmYkbeH0fDN1 8J19DF8F+/HDeNHlkH1I/vkW8adhjzWsRXPywMFvr8aWj4dNheUSufDOSxM8lxQ3 lOurRcAc/+WV/1X8EpEYXU/8zDCcpVOx7huzLamVrlp8K3c453kjc2oQIuTyvH5B 3i97Ltlz241wUnunm14JvV+PsbEbo69G5HXEIWkMimGEk0S+I0+Mp5ra1zcX2guf vrp1pI2o8EPI9FQafp30rDXEnMY7+14fhe58Cwi297rgJLCveWThKDy/UyNrhQK2 J75Nfp7x1Ipdspo2PTNcoMksoS2Hxs7/4Gw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrieefgdehvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 26 Jul 2023 21:59:33 -0400 (EDT) Message-ID: <95b66a01-f1af-d2b7-b10d-72e52c7fd07e@gutov.dev> Date: Thu, 27 Jul 2023 04:59:32 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#63870: 29.0.90; project.el can't dynamically populate the project list Content-Language: en-US To: Juri Linkov , Spencer Baugh References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> <864jm186cb.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <864jm186cb.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 63870 Cc: Eli Zaretskii , 63870@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 18/07/2023 20:41, Juri Linkov wrote: >> (Maybe I'll revisit this after writing some scripts like this for Emacs >> development - although those will definitely only be in Elisp, so it >> would be kind of moot) > Why can't project--ensure-read-project-list scan a list of known roots > to find a new project? I.e. the reverse of project-forget-projects-under. > > Or like there is an item "... (choose a dir)", another item could be > "*Rescan*" that will try to find a new project under known roots. We have an interactive command called 'project-remember-projects-under', when you want to trigger such a scan. But as for why we don't do that automatically? Performance, for instance. Tree traversal, coupled with arbitrary logic for finding projects, can be too costly.