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 15:43:53 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> (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"?
>
> That's one way, yes.  Another one is to use define-error to define a
> new error type for this case.

Instead of defining a new error type, how about just signaling
file-locked instead?  e.g. the following patch:

diff --git a/lisp/userlock.el b/lisp/userlock.el
index 61f061d3e54..e4d23c56249 100644
--- a/lisp/userlock.el
+++ b/lisp/userlock.el
@@ -67,7 +67,7 @@ ask-user-about-lock
         (message (substitute-command-keys
                   "%s locked by %s: (\\`s', \\`q', \\`p', \\`?')? ")
                  short-file short-opponent)
-       (if noninteractive (error "Cannot resolve lock conflict in batch mode"))
+       (if noninteractive (signal 'file-locked (list file opponent)))
        (let ((tem (let ((inhibit-quit t)
                         (cursor-in-echo-area t))
                     (prog1 (downcase (read-char))

Including also a documentation update to explain that when
noninteractive=t, a file lock conflict always signals file-locked
instead of prompting the user.

>> > 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.
>
> ??? Is project-current always used in a non-interactive context?  I
> don't think so.  When some interactive program calls it,
> noninteractive will be nil, and what userlock.el does in that case is
> not what you describe.

Right.

> And if you are saying that some program binds noninteractive to a
> non-nil value to avoid asking the file-locked question, then with the
> error-catching as discussed above in place, that program won't need to
> do that anymore, right?  (Also see below for why this binding is
> problematic in a more general sense.)

Yes, that's what I'm saying.  That's all correct.