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#50297: 28.0.50; Aggregate project functions for project.el Date: Fri, 3 Sep 2021 03:55:24 +0300 Message-ID: <729bfc0b-cb5f-c278-a4a4-60e4ef723f0f@yandex.ru> References: <87h7f5ok5l.fsf@posteo.net> <5c88cae7-4175-9c1e-cf20-188883e6e617@yandex.ru> <87mtovds0o.fsf@posteo.net> 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="7138"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 Cc: 50297@debbugs.gnu.org, Theodor Thornhill To: Philip Kaludercic Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Sep 03 02:56:13 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 1mLxV7-0001gP-9G for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 03 Sep 2021 02:56:13 +0200 Original-Received: from localhost ([::1]:60572 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mLxV5-0004qh-3s for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 02 Sep 2021 20:56:11 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41924) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mLxUw-0004qL-JU for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 20:56:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:59063) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mLxUw-0005mJ-C2 for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 20:56:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mLxUw-00070N-81 for bug-gnu-emacs@gnu.org; Thu, 02 Sep 2021 20:56: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: Fri, 03 Sep 2021 00:56:02 +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.163063053426892 (code B ref 50297); Fri, 03 Sep 2021 00:56:02 +0000 Original-Received: (at 50297) by debbugs.gnu.org; 3 Sep 2021 00:55:34 +0000 Original-Received: from localhost ([127.0.0.1]:42376 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLxUT-0006zg-L8 for submit@debbugs.gnu.org; Thu, 02 Sep 2021 20:55:33 -0400 Original-Received: from mail-wm1-f51.google.com ([209.85.128.51]:34610) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mLxUS-0006zT-8y for 50297@debbugs.gnu.org; Thu, 02 Sep 2021 20:55:32 -0400 Original-Received: by mail-wm1-f51.google.com with SMTP id v20-20020a1cf714000000b002e71f4d2026so2046021wmh.1 for <50297@debbugs.gnu.org>; Thu, 02 Sep 2021 17:55:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=2Z3DcOQ76u8YpkO5Ms9hGCAWo3DV33uIIq9d4aVpqSs=; b=mprEeWT2uh8/VVumYSLAwmRzECG3eNIpPqb/yBI4hvHXrS1+ywh7HBOaWANN+AWd0U 5XQDGdvQY/taUDmtsvBa2WIOAlGFgf9JJbKsWEs5Vepujm7R06mywH/24PRkSN9WNUX5 1plrazyq9uOVZHXljhilsk1iZhPWGxZmc/UAEsUjPBFQDP/0xLZTscolL60O/w/zLers 5+m8ntsRxuGIQNkZtrdfoHCZx8AocSuEx3sGDrNfIsJiwdgxs6pqqCWAL/swZpFtmEVN QILIwbEGOVU4rT5JQP2KVJ1UsZpD58Eskny2UdE3Ufrb+W/1iZ2TwLlwqlhRJodQDw4E aQZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=2Z3DcOQ76u8YpkO5Ms9hGCAWo3DV33uIIq9d4aVpqSs=; b=BLyEt8acHZroHLTlaYdWrdRkPvtjnZUL8gp5ez9U4lPCFh9gyh88N5VIgh/3T8Fs0X XyqjrTbisJoAeUdBMsyXUDdp9TCm95tiOLAALuPZOxcLvAkxpH1hCMJBvDU4jf+gXLFN RD0hKz7E1ENZ42+2i3O1QOm++6IWGURQzyOow0EswC6BKx1Dj4W+sRyoGQY9lxRQxHOK PgLTFnbT4g/mPGPjZ2wkwoeVhcqPwL1mMbCOHLMztRbEQlzo6nUNPq7njW8qHwVVJhBi bJFhqQj3TA+09EhhJc25ZEgOw4qsZHzBF5H1S9i0rbCqYydx1A07+9BEwMnsbzxegLut 0GZg== X-Gm-Message-State: AOAM530bebBWkbB0Jrg+OOS5eenqoKZuza6B6eo1n1/1kJdrrxcCkGD7 7jIDzixYxem5AgebLcdzZas= X-Google-Smtp-Source: ABdhPJzxht121mtag/lthy/NOfIi2ronBHb8TQMY2JILXp83zahEh0SkZ04HmwLUSCzFtM8nw0d6zQ== X-Received: by 2002:a1c:a9ce:: with SMTP id s197mr5542853wme.173.1630630526157; Thu, 02 Sep 2021 17:55:26 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k37sm2615194wms.18.2021.09.02.17.55.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 02 Sep 2021 17:55:25 -0700 (PDT) In-Reply-To: <87mtovds0o.fsf@posteo.net> Content-Language: en-US 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:213309 Archived-At: On 02.09.2021 16:30, Philip Kaludercic wrote: >>> - 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. I think it's usual enough, but since we try to enable all kinds of practices, we should try to handle as many as feasible. I'm mostly worried about the semantics here: we say we scan all the projects in said directory, but we can miss some (or many). That can be fixed with an edit to the docstring, of course (e.g. "directly below"). >> 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. It might be fine as it is, behavior-wise. It never occurred to me to ask or search for such functionality, though, so me might want to wait for others to chime in (who will want to use this). I'm usually fine with 'C-x C-f' when visiting a project the first time. >> 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. We might encounter some resistance (the command has been with us for half a year), but let's try it, at least. We can also ask Theodor whether he has already used the current name, project-remove-known-project, in some Lisp code. >> 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. We could skip remote projects entirely in that function (leaving it to the user to 'forget' them manually), or only do it for already connected hosts. The latter could still take some time, though. Do you expect project-forget-zombie-projects to be useful to remote hosts as well? Do you also have directories on remote hosts that contain many projects? >>> 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. Could you elaborate? Falsely meaning projects you simply don't want to return to? A whole directory of them? > An entirely different approach might be to implement a tabulated list > major mode to manage projects, comparable to package-list. I don't object to supporting this approach, built-in or in a third-party package, as long as we're reasonably sure there is no low-touch, automatic solution we can use with a similar success for the problem in question. If there's none, or if we found such, and then figured that some manual management on top of it can still be useful, that is fine.