From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Philip Kaludercic Newsgroups: gmane.emacs.bugs Subject: bug#50297: 28.0.50; Aggregate project functions for project.el Date: Thu, 02 Sep 2021 13:30:15 +0000 Message-ID: <87mtovds0o.fsf@posteo.net> References: <87h7f5ok5l.fsf@posteo.net> <5c88cae7-4175-9c1e-cf20-188883e6e617@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19179"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 50297@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Sep 02 15:51:49 2021 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 1mLn86-0004hU-0t for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 15:51:46 +0200 Original-Received: from localhost ([::1]:50858 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLn84-0006Ys-Rs for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 09:51:44 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:47864) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLmo4-0005tD-3G for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 09:31:04 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:56709) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLmo1-0003Br-RV for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 09:31:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mLmo1-0002Pq-Lf for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 09:31:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Philip Kaludercic Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 02 Sep 2021 13:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50297 X-GNU-PR-Package: emacs Original-Received: via spool by 50297-submit@debbugs.gnu.org id=B50297.16305894269240 (code B ref 50297); Thu, 02 Sep 2021 13:31:01 +0000 Original-Received: (at 50297) by debbugs.gnu.org; 2 Sep 2021 13:30:26 +0000 Original-Received: from localhost ([127.0.0.1]:40022 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLmnR-0002Oy-PT for submit@debbugs.gnu.org; Thu, 02 Sep 2021 09:30:26 -0400 Original-Received: from mout01.posteo.de ([185.67.36.65]:55827) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLmnP-0002Oj-GR for 50297@debbugs.gnu.org; Thu, 02 Sep 2021 09:30:24 -0400 Original-Received: from submission (posteo.de [89.146.220.130]) by mout01.posteo.de (Postfix) with ESMTPS id 41892240026 for <50297@debbugs.gnu.org>; Thu, 2 Sep 2021 15:30:16 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1630589417; bh=wRFn1O8pHYeCBO72IAT1VbCFhlhJyJqF9sSK9LmdTAQ=; h=From:To:Cc:Subject:Autocrypt:Date:From; b=IHtv3iAu/KSC3FOsyONpU0yLp6se7IX5EhI9XAJIk/oqfbyLAUXVmvEYoMH7lWPIi wjX5Lvvx2JrhjIwL15wETytTsG/34SQhHWLrQa9XMjoQXaFudPb0N2SuMpLETpb5P5 qLzqSZw4AfXZytYtAFFUOi5LOg8SGsVvCYBk5rWv7mEB41QIzobVhvb2IsxOF6ImPM uFm6dkm3zu38x8XYSanYraorDYeKvY5F5YV36gJIyDqOQlW+IAOcLG/ZaljeuwKfuA fHjbxEj3b+fMkJP8KqXD6kuOVcnLK2x/zYtMcmAgEWIBLMIBHFiUZSsrf7R9ccEZQv rpNn1EXONr/zw== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4H0hcm0Fchz6tmD; Thu, 2 Sep 2021 15:30:15 +0200 (CEST) Autocrypt: addr=philipk@posteo.net; prefer-encrypt=mutual; keydata= mDMEYHHqUhYJKwYBBAHaRw8BAQdAp3GdmYJ6tm5McweY6dEvIYIiry+Oz9rU4MH6NHWK0Ee0QlBo aWxpcCBLYWx1ZGVyY2ljIChnZW5lcmF0ZWQgYnkgYXV0b2NyeXB0LmVsKSA8cGhpbGlwa0Bwb3N0 ZW8ubmV0PoiQBBMWCAA4FiEEDM2H44ZoPt9Ms0eHtVrAHPRh1FwFAmBx6lICGwMFCwkIBwIGFQoJ CAsCBBYCAwECHgECF4AACgkQtVrAHPRh1FyTkgEAjlbGPxFchvMbxzAES3r8QLuZgCxeAXunM9gh io0ePtUBALVhh9G6wIoZhl0gUCbQpoN/UJHI08Gm1qDob5zDxnIHuDgEYHHqUhIKKwYBBAGXVQEF AQEHQNcRB+MUimTMqoxxMMUERpOR+Q4b1KgncDZkhrO2ql1tAwEIB4h4BBgWCAAgFiEEDM2H44Zo Pt9Ms0eHtVrAHPRh1FwFAmBx6lICGwwACgkQtVrAHPRh1Fw1JwD/Qo7kvtib8jy7puyWrSv0MeTS g8qIxgoRWJE/KKdkCLEA/jb9b9/g8nnX+UcwHf/4VfKsjExlnND3FrBviXUW6NcB In-Reply-To: <5c88cae7-4175-9c1e-cf20-188883e6e617@yandex.ru> (Dmitry Gutov's message of "Wed, 1 Sep 2021 04:07:39 +0300") 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" Xref: news.gmane.io gmane.emacs.bugs:213270 Archived-At: Dmitry Gutov writes: > Hi! > > On 31.08.2021 15:47, Philip Kaludercic wrote: >> The following patch introduces a few functions for aggregate project >> maintenance: >> - project-find-projects-under >> Select a directory with projects to index all at once. > > I wonder how popular this is going to be. Do you have a flat directory > with projects which you only want scanned one time? I clone most code into a directory, and I have seen others do so too. That being said, it might just be something unusual in the big picture. > Another issue, is that it's not going to find nested projects (and > project.el does support those). My first implementation of the command tried to so something like that, but it was rather slow (even if I currently only have 20 projects checked out), and indexed a lot of projects that I wasn't interested in. Maybe I can look into how it can be accelerated or only search for nested projects when a prefix argument is supplied/not supplied. > Suppose we do add it, how about the name > 'project-remember-projects-under'? By analogy with > 'project-remember-project'. I like it. > Adding a new arg for the latter is fine by me either way. > >> - project-remove-zombie-projects >> Check if all known projects still exist and remove those >> that don't anymore > > Perhaps we should rename 'project-remove-known-project' to > 'project-forget-known-project'? That would make for a nice symmetry. > > Then this function could be called 'project-forget-zombie-projects'. This also make sense. Initially I wanted to name the command that way, but then decided to go with "remove" to keep the naming consistent. > I'm thinking about this about the slight connotation of 'remove' which > can mean removing from disk. > > Another approach would be to call this or similar code automatically > before saving the list (and cap the number of remembered projects), > but that comes with its own tradeoffs. I can try it out, but I fear it might lead to annoying pauses, especially when a project was indexed via TRAMP. >> - project-remove-projects-under >> Remove all projects in a directory (inverse of >> project-find-projects-under). > > Similar question about popularity, but this one won't have a problem > with semantics, at least (recursive-vs-non-recursive). > >> Especially the last two are useful to maintain a clean project list >> without having to manually remove every project one by one. > > What if the goal was to maintain a clean project list but minimize the > manual management of it by the user? > > Can you imagine a solution for that? What would be the downsides, > compared to the present proposal? I can imagine zombie projects being cleaned up automatically, but the motivation to write project-remove-projects-under was to remove projects that were falsely indexed. An entirely different approach might be to implement a tabulated list major mode to manage projects, comparable to package-list. -- Philip Kaludercic