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

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:
>> Date: Thu, 9 Nov 2023 13:33:29 +0200
>> Cc: sbaugh@janestreet.com, 66993@debbugs.gnu.org
>> From: Dmitry Gutov <dmitry@gutov.dev>
>> 
>> 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 <dmitry@gutov.dev>
>> >>
>> >> 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!