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 15:18:59 +0300 Message-ID: <83edlvvky4.fsf@gnu.org> References: <83sfabvngh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1397"; 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 14:19:24 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 1qEU8p-00008u-Ls for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 28 Jun 2023 14:19:23 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qEU8a-0002ut-Vs; Wed, 28 Jun 2023 08:19:09 -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 1qEU8V-0002sU-Ru for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 08:19:04 -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 1qEU8V-0000IH-3u for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 08:19:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qEU8U-0005Fs-IQ for bug-gnu-emacs@gnu.org; Wed, 28 Jun 2023 08:19:02 -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 12:19:02 +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.168795472720179 (code B ref 63870); Wed, 28 Jun 2023 12:19:02 +0000 Original-Received: (at 63870) by debbugs.gnu.org; 28 Jun 2023 12:18:47 +0000 Original-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 Original-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 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 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==; 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 1qEU81-0006vV-HQ; Wed, 28 Jun 2023 08:18:34 -0400 In-Reply-To: (message from Spencer Baugh on Wed, 28 Jun 2023 08:05:23 -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:264210 Archived-At: > 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.