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

[Spencer Baugh <sbaugh@catern.com>]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@catern.com>
>> Date: Sat, 18 Nov 2023 23:10:43 +0000 (UTC)
>> Cc: dmitry@gutov.dev, sbaugh@janestreet.com, 66993@debbugs.gnu.org
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >> But actually, maybe it's time that we just enable savehist by default.
>> >
>> > Even if we decide to do that (and I'm not at all sure we should), how
>> > would that solve the difficulty pointed out by Dmitry?  Even if
>> > savehist is ON by default, the user could turn it OFF, right?
>> 
>> That's fine, we'd still be preserving backwards-compatibility:
>> project--list would still be saved by default.  The user could turn it
>> off, if they want, but that's not a problem - they can turn it off if
>> they want.
>
> IMNSHO, it is a very bad idea to have one feature turn on and off as a
> side effect of another, unrelated feature.  We should not have such
> inelegant dependencies.  savehist is a general-purpose feature which
> saves the history of important user actions, whereas the history of
> projects is a completely different feature from a much more narrow
> area of user activities.  They should not depend on one another, not
> directly anyway.

project-prompt-project-dir minibuffer history is is in fact the same
feature as (for example) read-file-name minibuffer history, we just
didn't realize it before and so we unnecessarily implemented separate
logic for persisting it.  If savehist had been on by default when
project.el was added, there would have been no need for the separate
logic.  So it makes sense for them to be unified.

(They can still be turned off independently with savehist configuration,
of course, if the user wants to)