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

[Eli Zaretskii <eliz@gnu.org>]

> 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.

> > 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.  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.)

> 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

(Didn't you just say it's a separate problem?)

It doesn't crash here, it exits with exit code -1.  Which is a direct
consequence of binding noninteractive non-nil: signaling an error in
that case shows the backtrace on stderr and exits.  "Kids, don't try
that at home!"