From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#63870: 29.0.90; project.el can't dynamically populate the project list Date: Wed, 28 Jun 2023 14:24:46 +0300 Message-ID: <83sfabvngh.fsf@gnu.org> References: Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="11069"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 63870@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Jun 28 13:25:19 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qETIV-0002fE-Ah for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Jun 2023 13:25:19 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qETIG-0000ik-VC; Wed, 28 Jun 2023 07:25:04 -0400 Original-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 1qETIE-0000iA-5j for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 07:25:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qETID-0002ML-SI for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 07:25:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qETID-0001Fu-Oi for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 07:25:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 28 Jun 2023 11:25:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63870 X-GNU-PR-Package: emacs Original-Received: via spool by 63870-submit@debbugs.gnu.org id=B63870.16879514714775 (code B ref 63870); Wed, 28 Jun 2023 11:25:01 +0000 Original-Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 11:24:31 +0000 Original-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 Original-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 Original-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==; Original-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 In-Reply-To: (message from Spencer Baugh on Tue, 27 Jun 2023 15:27:30 -0400) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:264201 Archived-At: > 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.