GNU bug report logs - #66993
[PATCH] project.el: avoid asking user about project-list-file lock

Previous Next

Full log

Message #14 received at 66993 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Spencer Baugh <sbaugh <at> janestreet.com>, Dmitry Gutov <dmitry <at> gutov.dev>
Cc: 66993 <at> debbugs.gnu.org
Subject: Re: bug#66993: [PATCH] project.el: avoid asking user about
 project-list-file lock
Date: Wed, 08 Nov 2023 14:22:31 +0200

> From: Spencer Baugh <sbaugh <at> janestreet.com>
> Date: Tue, 07 Nov 2023 16:28:04 -0500
> 
> There are several features which will cause Emacs to frequently call
> project-current, and therefore call project-remember-project, and
> therefore sometimes call project--write-project-list whenever a new
> project is seen.

Why does project-current immediately writes the list to the file?  Why
cannot it keep the information in memory and write it only when the
session ends, or at some random rare opportunity?

> - project-uniquify-dirname-transform will call this for each new
>   buffer
> 
> - project-mode-line will call this on mode-line update
> 
> - My own private project-watch will call this based on file-notify
>   events.

Ouch! this doesn't sound like a clean implementation to me.  Writing
something to a file from mode-line update? or when a new buffer is
created?  Why cannot we come up with a cleaner implementation?

> There's no correct answer the user can give to ask-user-about-lock:
> either way, one of the Emacs instances will have its project-list-file
> update lost.  So let's not even bother prompting the user: just do
> nothing if project-list-file is currently locked.

Sorry, that cannot be TRT.  We cannot second-guess what the user wants
to do in this case, and claim we are always right.

> In the long run, the update doesn't actually get lost, because the
> Emacs instance will probably make the same project-list-file update
> again a few seconds later due to a later call to project-current.  So
> this doesn't lose anything.

One more reason not to write the changes upon each change.  Or at
least detect that the file is locked, and schedule update at a later
time, or something.  Ideally, we should only write the file at exit.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.