all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Spencer Baugh <sbaugh@catern.com>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Spencer Baugh <sbaugh@janestreet.com>,
	66993@debbugs.gnu.org, dmitry@gutov.dev
Subject: bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock
Date: Fri, 10 Nov 2023 12:48:36 +0000 (UTC)	[thread overview]
Message-ID: <8734xd7p0h.fsf@catern.com> (raw)
In-Reply-To: <837cmqzp3m.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 09 Nov 2023 21:46:53 +0200")

[-- Attachment #1: Type: text/plain, Size: 3312 bytes --]

Eli Zaretskii <eliz@gnu.org> writes:
>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Cc: dmitry@gutov.dev,  66993@debbugs.gnu.org
>> Date: Thu, 09 Nov 2023 13:01:09 -0500
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> > Please show the result of this change on what Emacs prints in batch
>> > mode when this error is signaled.
>> 
>> Before:
>> 
>> $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")'
>> /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? 
>> 
>> Error: error ("Cannot resolve lock conflict in batch mode")
>>   mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x957865a77aef0ee>))
>>   debug-early-backtrace()
>>   debug-early(error (error "Cannot resolve lock conflict in batch mode"))
>>   signal(error ("Cannot resolve lock conflict in batch mode"))
>>   error("Cannot resolve lock conflict in batch mode")
>>   ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")
>>   write-region("foo" nil "~/file")
>>   eval((write-region "foo" nil "~/file") t)
>>   command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")"))
>>   command-line()
>>   normal-top-level()
>> Cannot resolve lock conflict in batch mode
>> 
>> 
>> After:
>> 
>> $ ./src/emacs -Q --batch --eval '(write-region "foo" nil "~/file")'
>> /home/sbaugh/file locked by sbaugh@igm-qw... (pid 3781848): (s, q, p, ?)? 
>> 
>> Error: file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")
>>   mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode 0x179d0e5a77aef0e7>))
>>   debug-early-backtrace()
>>   debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)"))
>>   signal(file-locked ("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)"))
>>   ask-user-about-lock("/home/sbaugh/file" "sbaugh@igm-qws-u22796a (pid 3781848)")
>>   write-region("foo" nil "~/file")
>>   eval((write-region "foo" nil "~/file") t)
>>   command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")"))
>>   command-line()
>>   normal-top-level()
>> /home/sbaugh/file: sbaugh@igm-qws-u22796a (pid 3781848)
>
> Thanks, that's what I thought: this loses information.  The "Cannot
> resolve lock conflict in batch mode" part is important, since it
> explains the "file-locked" part.  So please include the missing text
> in the list passed to 'signal' as its DATA argument, so as not to lose
> this explanation.

OK, how about this?  Which makes Emacs print:

Error: file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode")
  mapbacktrace(#f(compiled-function (evald func args flags) #<bytecode -0x1f22147a251783b>))
  debug-early-backtrace()
  debug-early(error (file-locked "/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode"))
  signal(file-locked ("/home/sbaugh/file" "sbaugh@earth (pid 1852838)" "Cannot resolve lock conflict in batch mode"))
  ask-user-about-lock("/home/sbaugh/file" "sbaugh@earth (pid 1852838)")
  write-region("foo" nil "~/file")
  eval((write-region "foo" nil "~/file") t)
  command-line-1(("--eval" "(write-region \"foo\" nil \"~/file\")"))
  command-line()
  normal-top-level()
/home/sbaugh/file: sbaugh@earth (pid 1852838), Cannot resolve lock conflict in batch mode


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Signal-file-locked-on-lock-conflict-with-noninteract.patch --]
[-- Type: text/x-diff, Size: 1776 bytes --]

From 9f94d8975406a3f4bdaa97ed8bd6a08dbf8e3d9b Mon Sep 17 00:00:00 2001
From: Spencer Baugh <sbaugh@catern.com>
Date: Fri, 10 Nov 2023 07:20:09 -0500
Subject: [PATCH] Signal file-locked on lock conflict with noninteractive=t

Previously we would signal a generic error on lock conflict when
noninteractive=t.  That meant that non-interactively handling a lock
conflict would require catching all errors and checking the string in
DATA.

Now we just signal file-locked instead, which matches the interactive
behavior when the user says "q" at the prompt.

Also, when noninteractive, we signal before we write the prompt about
the lock conflict.  That prompt usually gets in the way of
noninteractively handling and suppress lock conflict errors.  The
signal data contains all the necessary information, we don't need to
write a separate message for noninteractive.

* lisp/userlock.el (ask-user-about-lock): Signal file-locked on
noninteractive lock conflict.  (bug#66993)
---
 lisp/userlock.el | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/lisp/userlock.el b/lisp/userlock.el
index 4623608f1db..91d5b7308dd 100644
--- a/lisp/userlock.el
+++ b/lisp/userlock.el
@@ -64,10 +64,11 @@ ask-user-about-lock
 			  (match-string 0 opponent)))
 	      opponent))
       (while (null answer)
+	(when noninteractive
+          (signal 'file-locked (list file opponent "Cannot resolve lock conflict in batch mode")))
         (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"))
 	(let ((tem (let ((inhibit-quit t)
 			 (cursor-in-echo-area t))
 		     (prog1 (downcase (read-char))
-- 
2.39.2


  reply	other threads:[~2023-11-10 12:48 UTC|newest]

Thread overview: 55+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-11-07 21:28 bug#66993: [PATCH] project.el: avoid asking user about project-list-file lock Spencer Baugh
2023-11-08  0:24 ` Dmitry Gutov
2023-11-08 12:29   ` Eli Zaretskii
2023-11-08 13:20     ` Dmitry Gutov
2023-11-08 15:06   ` Spencer Baugh
2023-11-08  7:46 ` Michael Albinus
2023-11-08 14:52   ` Spencer Baugh
2023-11-08 15:44     ` Michael Albinus
2023-11-08 16:35       ` Eli Zaretskii
2023-11-08 12:22 ` Eli Zaretskii
2023-11-08 13:26   ` Dmitry Gutov
2023-11-08 13:50     ` Eli Zaretskii
2023-11-08 13:56       ` Dmitry Gutov
2023-11-08 15:31         ` Eli Zaretskii
2023-11-08 15:41           ` Spencer Baugh
2023-11-08 16:35             ` Eli Zaretskii
2023-11-08 17:05               ` Spencer Baugh
2023-11-08 17:43                 ` Eli Zaretskii
2023-11-08 20:43                   ` Spencer Baugh
2023-11-09  6:32                     ` Eli Zaretskii
2023-11-09 16:38                       ` Spencer Baugh
2023-11-09 16:52                         ` Eli Zaretskii
2023-11-09 18:01                           ` Spencer Baugh
2023-11-09 19:46                             ` Eli Zaretskii
2023-11-10 12:48                               ` Spencer Baugh [this message]
2023-11-15 13:38                                 ` Eli Zaretskii
2023-11-08 15:36     ` Spencer Baugh
2023-11-08 16:32       ` Eli Zaretskii
2023-11-08 21:04         ` Dmitry Gutov
2023-11-09  6:37           ` Eli Zaretskii
2023-11-09 11:05             ` Dmitry Gutov
2023-11-09 11:27               ` Eli Zaretskii
2023-11-09 11:33                 ` Dmitry Gutov
2023-11-09 14:50                   ` Eli Zaretskii
2023-11-15 15:40                     ` Spencer Baugh
2023-11-15 20:49                       ` Spencer Baugh
2023-11-18  1:41                         ` Dmitry Gutov
2023-11-18 15:48                           ` sbaugh
2023-11-18 15:56                             ` sbaugh
2023-11-18 16:26                             ` Eli Zaretskii
2023-11-18 23:10                               ` Spencer Baugh
2023-11-19  6:05                                 ` Eli Zaretskii
2023-11-19 14:54                                   ` Spencer Baugh
2023-11-19 14:31                               ` Dmitry Gutov
2023-11-19 15:23                                 ` Eli Zaretskii
2023-11-20  2:05                                   ` Dmitry Gutov
2023-11-20 11:57                                     ` Eli Zaretskii
2023-11-19 14:33                             ` Dmitry Gutov
2023-11-19 17:52                             ` Juri Linkov
2023-11-19 19:38                               ` Spencer Baugh
2023-11-20  1:19                                 ` Dmitry Gutov
2023-11-08 21:03       ` Dmitry Gutov
2023-11-08 13:58 ` Dmitry Gutov
2023-11-08 15:25   ` Spencer Baugh
2023-11-08 21:14     ` Dmitry Gutov

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8734xd7p0h.fsf@catern.com \
    --to=sbaugh@catern.com \
    --cc=66993@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.