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

[Spencer Baugh <sbaugh@janestreet.com>]

Dmitry Gutov <dmitry@gutov.dev> writes:

> On 08/11/2023 14:22, Eli Zaretskii wrote:
>>> From: Spencer Baugh<sbaugh@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?
>
> It could indeed be written from kill-emacs-hook, or just the next time
> an opportunity presents.

I like the idea of writing the file from kill-emacs-hook.  That seems
cleaner than writing the file at random times.

Alternatively, I suppose if we had a periodic timer that writes the
file, that timer could also do the somewhat useful maintenance work of
calling project-forget-zombie-projects.  Or maybe we could just call
that from kill-emacs-hook too?  Just a thought.

Separately: Currently, even without any locking issues, if there are
multiple Emacsen then project-list-file just contains the project--list
of the last one to write.  So they're constantly clobbering each others'
added and removed projects.  If we do the writes more rarely, then we
could try to read project-list-file first and add or remove the projects
that were added or removed during the life of this Emacs instance,
instead of just blindly writing out project--list.  Then if there are
multiple Emacsen around, their changes to project--list won't clobber
each other, they'll just be cleanly merged.  Does that sound reasonable?

Either way, I can implement this.