From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#63870: 29.0.90; project.el can't dynamically populate the project list Date: Tue, 18 Jul 2023 05:21:37 +0300 Message-ID: <9a053f1f-2c7b-0b50-3a8e-7949fbbac7d1@gutov.dev> References: <83sfabvngh.fsf@gnu.org> <83edlvvky4.fsf@gnu.org> <83bkgzvj7h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3438"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Cc: 63870@debbugs.gnu.org To: Eli Zaretskii , Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 18 04:22:26 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 1qLaM4-0000cE-Ko for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Jul 2023 04:22:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLaLl-00088a-FQ; Mon, 17 Jul 2023 22:22:05 -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 1qLaLj-000886-5Q for bug-gnu-emacs@gnu.org; Mon, 17 Jul 2023 22:22:03 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qLaLi-0008Or-TM for bug-gnu-emacs@gnu.org; Mon, 17 Jul 2023 22:22:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qLaLi-0008NN-HQ for bug-gnu-emacs@gnu.org; Mon, 17 Jul 2023 22:22:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Jul 2023 02:22: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.168964691232179 (code B ref 63870); Tue, 18 Jul 2023 02:22:02 +0000 Original-Received: (at 63870) by debbugs.gnu.org; 18 Jul 2023 02:21:52 +0000 Original-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 Original-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 Original-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) Original-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 Original-Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jul 2023 22:21:39 -0400 (EDT) Content-Language: en-US In-Reply-To: <83bkgzvj7h.fsf@gnu.org> 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:265421 Archived-At: 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.