From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Spencer Baugh Newsgroups: gmane.emacs.bugs Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Date: Wed, 15 Nov 2023 10:40:33 -0500 Message-ID: References: <83sf5g1lko.fsf@gnu.org> <9d460f36-6035-da54-3abc-12171ac8977f@gutov.dev> <83h6lw19zw.fsf@gnu.org> <894f674f-76ea-90af-3acc-73ca6e7caf35@gutov.dev> <834jhv1lfw.fsf@gnu.org> <83ttpvyxn0.fsf@gnu.org> <42fe7d0e-024c-3e0d-3bc5-b0e6ec50f260@gutov.dev> <83r0kzyo93.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9299"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Dmitry Gutov , 66993@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 15 16:42:29 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 1r3I27-00026x-E7 for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 15 Nov 2023 16:42:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r3I1z-0003eO-0c; Wed, 15 Nov 2023 10:42:19 -0500 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 1r3I1q-0003Yu-3Q for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2023 10:42:10 -0500 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 1r3I1p-0000m7-I2 for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2023 10:42:09 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r3I1m-0000ce-8H for bug-gnu-emacs@gnu.org; Wed, 15 Nov 2023 10:42:06 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Spencer Baugh Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 15 Nov 2023 15:42:06 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66993 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66993-submit@debbugs.gnu.org id=B66993.17000628632280 (code B ref 66993); Wed, 15 Nov 2023 15:42:06 +0000 Original-Received: (at 66993) by debbugs.gnu.org; 15 Nov 2023 15:41:03 +0000 Original-Received: from localhost ([127.0.0.1]:52910 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3I0T-0000Zs-HF for submit@debbugs.gnu.org; Wed, 15 Nov 2023 10:41:01 -0500 Original-Received: from mxout5.mail.janestreet.com ([64.215.233.18]:49163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r3I0M-0000ZW-9R for 66993@debbugs.gnu.org; Wed, 15 Nov 2023 10:40:39 -0500 In-Reply-To: <83r0kzyo93.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 16:50:32 +0200") 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:274345 Archived-At: Eli Zaretskii writes: >> Date: Thu, 9 Nov 2023 13:33:29 +0200 >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 09/11/2023 13:27, Eli Zaretskii wrote: >> >> Date: Thu, 9 Nov 2023 13:05:09 +0200 >> >> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org >> >> From: Dmitry Gutov >> >> >> >> And what happens after the restart? The list needs to be recovered. >> > >> > Why does it need to be recovered? Isn't it built on-the-fly anyway? >> > Is this just some kind of optimization? >> >> If we didn't need to read it after restart, there would be no point in >> writing the list to disk. >> >> > I guess I don't understand well enough why this file exists and how it >> > is used? >> >> Same reason as for savehist-file. > > It's a history of projects in the last session? Then it's one more > reason to write the file only at exit, I guess? This comparison to savehist-file actually makes me think: Why don't we just make project--list into a history variable, and persist it like savehist? It would already be quite nice to have a history variable project-history for project-prompter, I've been thinking about implementing that. It would be convenient for: - switching repeatedly between two projects - running a project command accidentally outside a project and wanting to run it in the most recently used project. But then, if we have project-history, could the project file just be a persisted project-history? If we had this model, project-remember-project would be basically (push project 'project-history) project-forget-zombie-projects would naturally not be needed, because any zombie projects wouldn't be visited as part of the project-history, and so if the history was limited in size, they'd eventually just drop off the end. project-switch-project would prompt for anything on project-history. I think it simplifies things quite a lot!