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

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: dmitry@gutov.dev,  66993@debbugs.gnu.org
>> Date: Wed, 08 Nov 2023 12:05:38 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> > Not sure I follow: userlock.el signals a very specific error, doesn't
>> > it?  Or what am I missing?
>> 
>> By that you mean file-locked?  It only signals file-locked if it first
>> prompts the user, which is what we want to avoid.  If noninteractive=t,
>> then it just signals error:
>> 
>> (if noninteractive (error "Cannot resolve lock conflict in batch mode"))
>
> And that is not specific enough?

Are you suggesting that we should condition-case and check the string
inside the error is "Cannot resolve lock conflict in batch mode"?
Otherwise, if we just catch all errors, this will also catch and
suppress errors for failures to write to the file, which would be bad.

> And why the noninteractive=t case is relevant here, btw?

Because we don't want to prompt the user, we just want to signal an
error if there's a lock conflict.

>> Possibly we should just change that to signal file-locked too.
>
> Or something else.  If needed.
>
> In any case, these are minor details, the main point is that this
> error can be caught.

Well... the other issue is that Emacs crashes if you bind
noninteractive=t and then hit a lock conflict.  e.g.:

1. Open ~/file and edit it without saving (so Emacs takes the lock)
2. in a separate emacs -Q, run with M-:
(let ((noninteractive t)) (write-region nil nil "~/file"))
3. The emacs -Q crashes