X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: monnier@HIDDEN, bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 20 Jul 2024 15:48:02 +0000
Resent-Message-ID: <handler.72212.B.172149047429280 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: report 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 72212 <at> debbugs.gnu.org
Cc: monnier@HIDDEN
X-Debbugs-Original-To: bug-gnu-emacs@HIDDEN
X-Debbugs-Original-Xcc: monnier@HIDDEN
Received: via spool by submit <at> debbugs.gnu.org id=B.172149047429280
(code B ref -1); Sat, 20 Jul 2024 15:48:02 +0000
Received: (at submit) by debbugs.gnu.org; 20 Jul 2024 15:47:54 +0000
Received: from localhost ([127.0.0.1]:53820 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sVCJN-0007cB-5o
for submit <at> debbugs.gnu.org; Sat, 20 Jul 2024 11:47:54 -0400
Received: from lists.gnu.org ([209.51.188.17]:57488)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sVCJI-0007c2-Uh
for submit <at> debbugs.gnu.org; Sat, 20 Jul 2024 11:47:51 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10])
by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
id 1sVCJH-0000KJ-SK
for bug-gnu-emacs@HIDDEN; Sat, 20 Jul 2024 11:47:48 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <monnier@HIDDEN>)
id 1sVCJF-0003aQ-2p
for bug-gnu-emacs@HIDDEN; Sat, 20 Jul 2024 11:47:47 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B3723441BE0;
Sat, 20 Jul 2024 11:47:42 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1721490458;
bh=YZWhVir4Gj55Nl1z0e3A1En5WAfTIGNqPDDNjGTq85o=;
h=From:To:Subject:Date:From;
b=RUi+vWfMbOduqXfF4SOlyynFfwHd10ZbZxRAvnFxlzJbXhtBvRTMd1cbJ7cgcx+gC
IHTj343LS4btwlaQELu74A5mOxEcG9C9A+7rJXMR/VWQybK8qRg02QGp5zsv4/dAx2
EuqT3LujzRIMCN/zWZ+7V4BGPy7Ap+6EJ4nJjJPhV19W+nC0VWC/2lyv1ZpWs9LvWP
lnmEVM1AsBNw6fUUXHMHA/VcMUoSEMFCDsD5cG9PTxTWyv4diGMd5nhZ7H2kRcUSX/
6yht1g55lgI4kDpaXcaY/IGlkof4nkqLQJ32VFLzBp8ROMkV9WnadI4zQ1hdRIi/n5
/gVa9G23RS5pA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8DBB1441B21;
Sat, 20 Jul 2024 11:47:38 -0400 (EDT)
Received: from pastel (unknown [45.72.245.253])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 61B8E120403;
Sat, 20 Jul 2024 11:47:38 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
Message-ID: <jwvo76s5beg.fsf-monnier+@gnu.org>
Date: Sat, 20 Jul 2024 11:47:37 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.295 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
PROLO_LEO1 0.1 Meta Catches all Leo drug variations so far
X-SPAM-LEVEL:
Received-SPF: pass client-ip=132.204.25.50;
envelope-from=monnier@HIDDEN; helo=mailscanner.iro.umontreal.ca
X-Spam_score_int: -42
X-Spam_score: -4.3
X-Spam_bar: ----
X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3,
SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)
--=-=-=
Content-Type: text/plain
Package: Emacs
Version: 31.0.50
I think we should clean up our use of "condition objects", i.e. those
objects created (internally) by `signal` and then passed back to ELisp
via the VAR argument of `condition-case`.
I manually re-ordered the patch so that it starts with `subr.el` where
you can see the new definitions I suggest, and then the rest of the
patch illustrates how they'd be used.
The patch is not intended to be installed as-is because it changes some
files which need to preserve backward compatibility with Emacsen without
the new API.
Also the patch lacks the "main" change which would be to replace the
(almost 100) occurrences of
(signal (car FOO) (cdr FOO))
with
(condition-resignal FOO)
Beside whether we want to do this or not, there is another question
about naming: currently we use "condition" in some places (e.g. in
`condition-case`) but we use "error" in others (e.g. `define-error` and
`error-message-string`). I chose to use "condition" in the patch below,
but I don't have a strong opinion on that choice, so I could go with
"error" if that's what other prefer. If we keep "condition" there's the
subsidiary question whether we should add aliases for `define-error` and
`error-message-string`.
Stefan
--=-=-=
Content-Type: text/x-diff
Content-Disposition: inline; filename=condition.patch
diff --git a/lisp/subr.el b/lisp/subr.el
index 8c20fc5e9d4..cec6747dfcc 100644
--- a/lisp/subr.el
+++ b/lisp/subr.el
@@ -503,6 +503,7 @@ user-error
the `command-error-function' variable."
(signal 'user-error (list (apply #'format-message format args))))
+;; FIXME: Arguably, this should be called `define-condition'.
(defun define-error (name message &optional parent)
"Define NAME as a new error signal.
MESSAGE is a string that will be output to the echo area if such an error
@@ -523,6 +524,50 @@ define-error
(delete-dups (copy-sequence (cons name conditions))))
(when message (put name 'error-message message))))
+(defun condition-resignal (condition)
+ "Re-signal the CONDITION.
+CONDITION should be an object like those constructed by `signal' and
+captured in the VAR of `condition-case'. This will signal the condition
+again, like `signal' would do, but preserves the identity of CONDITION
+instead of constructing a new object."
+ (unless (and (car-safe condition) (symbolp (car condition)))
+ (error "Not a condition object: %S" condition))
+ ;; `signal' happens to have an undocumented calling convention
+ ;; that does just what we need.
+ (signal condition nil))
+
+(defalias 'condition-type #'car
+ "Return the symbol which represents the type of CONDITION.
+
+(fn CONDITION)")
+
+(defalias 'condition-data #'cdr
+ "Return the slots attached to CONDITION, as a list.
+
+(fn CONDITION)")
+
+(defun condition-hastype-p (condition type)
+ "Return non-nil if CONDITION is of type TYPE (or a subtype of it)."
+ (memq type (get (car condition) 'error-conditions)))
+
+(defun condition-type-p (symbol)
+ "Return non-nil if SYMBOL is a condition type."
+ ;; FIXME: Should we also test `error-message'?
+ (get (car condition) 'error-conditions))
+
+(defun conditionp (object)
+ "Return non-nil if OBJECT is a condition."
+ (let ((type (car-safe object)))
+ (condition-type-p type)))
+
+(defalias 'condition-slot-value #'elt
+ "Access the SLOT of object CONDITION.
+
+(fn CONDITION SLOT)")
+
+;; FIXME: Make it more flexible!
+(defalias 'condition-message-string #'error-message-string)
+
;; We put this here instead of in frame.el so that it's defined even on
;; systems where frame.el isn't loaded.
(defun frame-configuration-p (object)
diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
index 88167fc7ebd..e6578c8d42f 100644
--- a/lisp/emacs-lisp/bytecomp.el
+++ b/lisp/emacs-lisp/bytecomp.el
@@ -4986,9 +4986,9 @@ byte-compile-condition-case
(unless (and c (symbolp c))
(byte-compile-warn-x
c "`%S' is not a condition name (in condition-case)" c))
- ;; In reality, the `error-conditions' property is only required
+ ;; In reality, the `error-conditions' property is required only
;; for the argument to `signal', not to `condition-case'.
- ;;(unless (consp (get c 'error-conditions))
+ ;;(unless (condition-type-p c)
;; (byte-compile-warn
;; "`%s' is not a known condition name (in condition-case)"
;; c))
@@ -5729,6 +5729,8 @@ batch-byte-compile-file
(condition-case err
(byte-compile-file file)
(file-error
+ ;; FIXME: We should either `prin1' the whole ERR object
+ ;; or use `error-message-string' rather than this half-way thing.
(message (if (cdr err)
">>Error occurred processing %s: %s (%s)"
">>Error occurred processing %s: %s")
diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
index ec947c1215d..08ecf50e82f 100644
--- a/lisp/emacs-lisp/debug.el
+++ b/lisp/emacs-lisp/debug.el
@@ -563,9 +563,7 @@ debugger-eval-expression
(condition-case err
(backtrace-eval exp nframe base)
(error (setq errored
- (format "%s: %s"
- (get (car err) 'error-message)
- (car (cdr err)))))))))
+ (error-message-string err)))))))
(if errored
(progn
(message "Error: %s" errored)
diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
index deebe5109bd..ebc33731b75 100644
--- a/lisp/emacs-lisp/edebug.el
+++ b/lisp/emacs-lisp/edebug.el
@@ -3701,9 +3701,7 @@ edebug-safe-eval
;; If there is an error, a string is returned describing the error.
(condition-case edebug-err
(edebug-eval expr)
- (error (edebug-format "%s: %s" ;; could
- (get (car edebug-err) 'error-message)
- (car (cdr edebug-err))))))
+ (error (error-message-string edebug-err))))
;;; Printing
@@ -3711,14 +3709,7 @@ edebug-safe-eval
(defun edebug-report-error (value)
;; Print an error message like command level does.
;; This also prints the error name if it has no error-message.
- (message "%s: %s"
- (or (get (car value) 'error-message)
- (format "peculiar error (%s)" (car value)))
- (mapconcat (lambda (edebug-arg)
- ;; continuing after an error may
- ;; complain about edebug-arg. why??
- (prin1-to-string edebug-arg))
- (cdr value) ", ")))
+ (message "%s" (error-message-string value)))
;; Alternatively, we could change the definition of
;; edebug-safe-prin1-to-string to only use these if defined.
@@ -3767,10 +3758,7 @@ edebug-eval-expression
(condition-case err
(edebug-eval expr)
(error
- (setq errored
- (format "%s: %s"
- (get (car err) 'error-message)
- (car (cdr err)))))))))
+ (setq errored (error-message-string err)))))))
(result
(unless errored
(values--store-value value)
diff --git a/lisp/emacs-lisp/elint.el b/lisp/emacs-lisp/elint.el
index 27c169cc657..7d26346c6da 100644
--- a/lisp/emacs-lisp/elint.el
+++ b/lisp/emacs-lisp/elint.el
@@ -146,6 +146,8 @@ elint-unknown-builtin-args
"Those built-ins for which we can't find arguments, if any.")
(defvar elint-extra-errors '(file-locked file-supersession ftp-error)
+ ;; FIXME: We should define these conditions properly to make
+ ;; `elint-extra-errors' obsolete.
"Errors without `error-message' or `error-conditions' properties.")
(defconst elint-preloaded-skip-re
@@ -453,6 +456,7 @@ elint-init-form
(setq elint-env (elint-env-add-macro elint-env (cadr form)
(cons 'lambda (cddr form)))
elint-env (elint-env-add-func elint-env (cadr form) (nth 2 form))))
+ ;; FIXME: Recognize `define-error' instead!
((and (eq (car form) 'put)
(= 4 (length form))
(eq (car-safe (cadr form)) 'quote)
@@ -877,8 +881,7 @@ elint-check-condition-case-form
(dolist (err (nthcdr 3 form))
(setq errlist (car err))
(mapc (lambda (s)
- (or (get s 'error-conditions)
- (get s 'error-message)
+ (or (condition-type-p s)
(memq s elint-extra-errors)
(elint-warning
"Not an error symbol in error handler: %s" s)))
diff --git a/lisp/emacs-lisp/ert.el b/lisp/emacs-lisp/ert.el
index 6a665c8181d..81a7e8ca62e 100644
--- a/lisp/emacs-lisp/ert.el
+++ b/lisp/emacs-lisp/ert.el
@@ -396,12 +396,12 @@ ert--should-error-handle-error
Determines whether CONDITION matches TYPE and EXCLUDE-SUBTYPES,
and aborts the current test as failed if it doesn't."
- (let ((signaled-conditions (get (car condition) 'error-conditions))
- (handled-conditions (pcase-exhaustive type
+ (let ((handled-conditions (pcase-exhaustive type
((pred listp) type)
((pred symbolp) (list type)))))
- (cl-assert signaled-conditions)
- (unless (cl-intersection signaled-conditions handled-conditions)
+ (cl-assert (conditionp condition))
+ (unless (cl-some (lambda (hc) (condition-hastype-p condition hc))
+ handled-conditions)
(ert-fail (append
(funcall form-description-fn)
(list
diff --git a/lisp/epa-file.el b/lisp/epa-file.el
index 90cc91e99a0..7e1224e0c70 100644
--- a/lisp/epa-file.el
+++ b/lisp/epa-file.el
@@ -117,10 +117,10 @@ epa-file--find-file-not-found-function
(let ((error epa-file-error))
(save-window-excursion
(kill-buffer))
- (if (nth 3 error)
- (user-error "Wrong passphrase: %s" (nth 3 error))
+ (if (condition-slot-value error 3)
+ (user-error "Wrong passphrase: %s" (condition-slot-value error 3))
(signal 'file-missing
- (cons "Opening input file" (cdr error))))))
+ (cons "Opening input file" (condition-data error))))))
(defun epa--wrong-password-p (context)
"Return whether a wrong password caused the error in CONTEXT."
@@ -171,23 +171,25 @@ epa-file-insert-file-contents
;; signal that as a non-file error
;; so that find-file-noselect-1 won't handle it.
;; Borrowed from jka-compr.el.
- (if (and (memq 'file-error (get (car error) 'error-conditions))
- (equal (cadr error) "Searching for program"))
+ (if (and (condition-hastype-p error 'file-error)
+ (equal (condition-slot-value error 1)
+ "Searching for program"))
(error "Decryption program `%s' not found"
- (nth 3 error)))
+ (condition-slot-value error 3)))
(let ((exists (file-exists-p local-file)))
(when exists
(if-let ((wrong-password (epa--wrong-password-p context)))
;; Don't display the *error* buffer if we just
;; have a wrong password; let the later error
;; handler notify the user.
- (setq error (append error (list wrong-password)))
+ (setf (cdr error) ;FIXME: `condition-data'!
+ (append (cdr error) (list wrong-password)))
(epa-display-error context))
;; When the .gpg file isn't an encrypted file (e.g.,
;; it's a keyring.gpg file instead), then gpg will
;; say "Unexpected exit" as the error message. In
;; that case, just display the bytes.
- (if (equal (caddr error) "Unexpected; Exit")
+ (if (equal (condition-slot-value error 2) "Unexpected; Exit")
(setq string (with-temp-buffer
(insert-file-contents-literally local-file)
(buffer-string)))
@@ -197,10 +199,10 @@ epa-file-insert-file-contents
;; `find-file-noselect-1'.
(setq-local epa-file-error error)
(add-hook 'find-file-not-found-functions
- 'epa-file--find-file-not-found-function
+ #'epa-file--find-file-not-found-function
nil t)))
(signal (if exists 'file-error 'file-missing)
- (cons "Opening input file" (cdr error))))))
+ (cons "Opening input file" (condition-data error))))))
(set-buffer buf) ;In case timer/filter changed/killed it (bug#16029)!
(setq-local epa-file-encrypt-to
(mapcar #'car (epg-context-result-for
diff --git a/lisp/jka-compr.el b/lisp/jka-compr.el
index 0a14f0ab2b7..d0b75d7e3be 100644
--- a/lisp/jka-compr.el
+++ b/lisp/jka-compr.el
@@ -471,22 +471,21 @@ jka-compr-insert-file-contents
;; If the file we wanted to uncompress does not exist,
;; handle that according to VISIT as `insert-file-contents'
;; would, maybe signaling the same error it normally would.
- (if (and (eq (car error-code) 'file-missing)
- (eq (nth 3 error-code) local-file))
+ (if (and (condition-hastype-p error-code 'file-missing)
+ (eq (condition-slot-value error-code 3) local-file))
(if visit
(setq notfound error-code)
- (signal 'file-missing
- (cons "Opening input file"
- (nthcdr 2 error-code))))
+ (setf (condition-slot-value error-code 1)
+ "Opening input file")
+ (condition-resignal error-code))
;; If the uncompression program can't be found,
;; signal that as a non-file error
;; so that find-file-noselect-1 won't handle it.
- (if (and (memq 'file-error (get (car error-code)
- 'error-conditions))
+ (if (and (condition-hastype-p error-code 'file-error)
(equal (cadr error-code) "Searching for program"))
(error "Uncompression program `%s' not found"
- (nth 3 error-code)))
- (signal (car error-code) (cdr error-code)))))))
+ (nth 3 error-code))
+ (condition-resignal error-code)))))))
(and
local-copy
diff --git a/lisp/net/sasl.el b/lisp/net/sasl.el
index eb3d94475b9..79fabb42a0d 100644
--- a/lisp/net/sasl.el
+++ b/lisp/net/sasl.el
@@ -50,8 +50,7 @@ sasl-mechanism-alist
(defvar sasl-unique-id-function #'sasl-unique-id-function)
-(put 'sasl-error 'error-message "SASL error")
-(put 'sasl-error 'error-conditions '(sasl-error error))
+(define-error 'sasl-error "SASL error")
(defun sasl-error (datum)
(signal 'sasl-error (list datum)))
diff --git a/lisp/net/soap-client.el b/lisp/net/soap-client.el
index de04d58ed18..41f9e254de2 100644
--- a/lisp/net/soap-client.el
+++ b/lisp/net/soap-client.el
@@ -2886,7 +2886,7 @@ soap-decode-array
;;;; Soap Envelope parsing
-(if (fboundp 'define-error)
+(if (fboundp 'define-error) ;Emacs-24.4
(define-error 'soap-error "SOAP error")
;; Support Emacs<24.4 that do not have define-error, so
;; that soap-client can remain unchanged in GNU ELPA.
diff --git a/lisp/net/tramp-compat.el b/lisp/net/tramp-compat.el
index 8781230c00c..4fae2ae73c0 100644
--- a/lisp/net/tramp-compat.el
+++ b/lisp/net/tramp-compat.el
@@ -247,12 +247,12 @@ 'tramp-compat-always
;; `permission-denied' is introduced in Emacs 29.1.
(defconst tramp-permission-denied
- (if (get 'permission-denied 'error-conditions) 'permission-denied 'file-error)
+ (if (condition-type-p 'permission-denied) 'permission-denied 'file-error)
"The error symbol for the `permission-denied' error.")
(defsubst tramp-compat-permission-denied (vec file)
"Emit the `permission-denied' error."
- (if (get 'permission-denied 'error-conditions)
+ (if (condition-type-p 'permission-denied)
(tramp-error vec tramp-permission-denied file)
(tramp-error vec tramp-permission-denied "Permission denied: %s" file)))
diff --git a/lisp/net/tramp-message.el b/lisp/net/tramp-message.el
index 36079c8844c..de6ba65037c 100644
--- a/lisp/net/tramp-message.el
+++ b/lisp/net/tramp-message.el
@@ -380,8 +380,12 @@ tramp-error
vec-or-proc 1 "%s"
(error-message-string
(list signal
+ ;; FIXME: Looks redundant since `error-message-string'
+ ;; already uses the `error-message' property of `signal'!
(get signal 'error-message)
(apply #'format-message fmt-string arguments))))
+ ;; FIXME: This doesn't look right: ELisp code should be able to rely on
+ ;; the "shape" of the list based on the type of the signal.
(signal signal (list (substring-no-properties
(apply #'format-message fmt-string arguments))))))
diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
index 9bf6f9217c8..2e2da3ca103 100644
--- a/lisp/progmodes/elisp-mode.el
+++ b/lisp/progmodes/elisp-mode.el
@@ -703,8 +703,7 @@ elisp-completion-at-point
;; specific completion table in more cases.
(is-ignore-error
(list t (elisp--completion-local-symbols)
- :predicate (lambda (sym)
- (get sym 'error-conditions))))
+ :predicate #'condition-type-p))
((elisp--expect-function-p beg)
(list nil (elisp--completion-local-symbols)
:predicate
@@ -778,12 +777,11 @@ elisp-completion-at-point
(forward-sexp 2)
(< (point) beg)))))
(list t (elisp--completion-local-symbols)
- :predicate (lambda (sym) (get sym 'error-conditions))))
+ :predicate #'condition-type-p))
;; `ignore-error' with a list CONDITION parameter.
('ignore-error
(list t (elisp--completion-local-symbols)
- :predicate (lambda (sym)
- (get sym 'error-conditions))))
+ :predicate #'condition-type-p))
((and (or ?\( 'let 'let*)
(guard (save-excursion
(goto-char (1- beg))
diff --git a/lisp/simple.el b/lisp/simple.el
index 5961afa20e9..28a6553892d 100644
--- a/lisp/simple.el
+++ b/lisp/simple.el
@@ -3364,7 +3364,7 @@ minibuffer-error-function
The same as `command-error-default-function' but display error messages
at the end of the minibuffer using `minibuffer-message' to not obscure
the minibuffer contents."
- (if (memq 'minibuffer-quit (get (car data) 'error-conditions))
+ (if (condition-hastype-p data 'minibuffer-quit)
(ding t)
(discard-input)
(ding))
diff --git a/lisp/startup.el b/lisp/startup.el
index f18795ae6ac..ee04f5ca3ae 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1124,15 +1124,12 @@ startup--load-user-init-file
(display-warning
'initialization
(format-message "\
-An error occurred while loading `%s':\n\n%s%s%s\n\n\
+An error occurred while loading `%s':\n\n%s\n\n\
To ensure normal operation, you should investigate and remove the
cause of the error in your initialization file. Start Emacs with
the `--debug-init' option to view a complete error backtrace."
user-init-file
- (get (car error) 'error-message)
- (if (cdr error) ": " "")
- (mapconcat (lambda (s) (prin1-to-string s t))
- (cdr error) ", "))
+ (error-message-string error))
:warning)
(setq init-file-had-error t))))))
@@ -1431,15 +1428,12 @@ command-line
(princ
(if (eq (car error) 'error)
(apply #'concat (cdr error))
- (if (memq 'file-error (get (car error) 'error-conditions))
+ (if (condition-hastype-p error 'file-error)
(format "%s: %s"
(nth 1 error)
(mapconcat (lambda (obj) (prin1-to-string obj t))
(cdr (cdr error)) ", "))
- (format "%s: %s"
- (get (car error) 'error-message)
- (mapconcat (lambda (obj) (prin1-to-string obj t))
- (cdr error) ", "))))
+ (error-message-string error)))
'external-debugging-output)
(terpri 'external-debugging-output)
(setq initial-window-system nil)
diff --git a/lisp/type-break.el b/lisp/type-break.el
index 182f4656b16..bf32c69434e 100644
--- a/lisp/type-break.el
+++ b/lisp/type-break.el
@@ -1025,7 +1025,7 @@ type-break-demo-life
(setq continue nil)
(and (get-buffer "*Life*")
(kill-buffer "*Life*"))
- (condition-case ()
+ (condition-case err
(progn
(life 3)
;; wait for user to return
@@ -1033,7 +1033,7 @@ type-break-demo-life
(type-break-catch-up-event)
(kill-buffer "*Life*"))
(life-extinct
- (message "%s" (get 'life-extinct 'error-message))
+ (message "%s" (error-message-string err))
;; restart demo
(setq continue t))
(quit
--=-=-=--
Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) Content-Type: text/plain; charset=utf-8 X-Loop: help-debbugs@HIDDEN From: help-debbugs@HIDDEN (GNU bug Tracking System) To: Stefan Monnier <monnier@HIDDEN> Subject: bug#72212: Acknowledgement (31.0.50; API for condition objects) Message-ID: <handler.72212.B.172149047429280.ack <at> debbugs.gnu.org> References: <jwvo76s5beg.fsf-monnier+@gnu.org> X-Gnu-PR-Message: ack 72212 X-Gnu-PR-Package: emacs Reply-To: 72212 <at> debbugs.gnu.org Date: Sat, 20 Jul 2024 15:48:02 +0000 Thank you for filing a new bug report with debbugs.gnu.org. This is an automatically generated reply to let you know your message has been received. Your message is being forwarded to the package maintainers and other interested parties for their attention; they will reply in due course. As you requested using X-Debbugs-CC, your message was also forwarded to monnier@HIDDEN (after having been given a bug report number, if it did not have one). Your message has been sent to the package maintainer(s): bug-gnu-emacs@HIDDEN If you wish to submit further information on this problem, please send it to 72212 <at> debbugs.gnu.org. Please do not send mail to help-debbugs@HIDDEN unless you wish to report a problem with the Bug-tracking system. --=20 72212: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D72212 GNU Bug Tracking System Contact help-debbugs@HIDDEN with problems
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 19 Aug 2024 13:11:02 +0000
Resent-Message-ID: <handler.72212.B72212.172407300813796 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: 72212 <at> debbugs.gnu.org
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.172407300813796
(code B ref 72212); Mon, 19 Aug 2024 13:11:02 +0000
Received: (at 72212) by debbugs.gnu.org; 19 Aug 2024 13:10:08 +0000
Received: from localhost ([127.0.0.1]:57902 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sg299-0003aP-IA
for submit <at> debbugs.gnu.org; Mon, 19 Aug 2024 09:10:08 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:9917)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sg295-0003ZS-Um
for 72212 <at> debbugs.gnu.org; Mon, 19 Aug 2024 09:10:05 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4790B100055;
Mon, 19 Aug 2024 09:09:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1724072954;
bh=Bzwn6pePFYQsnqzgIf7SLexEv7rgpFC5QCviaYUK6DE=;
h=From:To:Subject:In-Reply-To:References:Date:From;
b=dx9qLTqj7Mpp8KI42pR80RMF1Yb6nY8kA0DEYSm5VrOoQMtypFlFXYaBiBP1IymfP
uSRzDCpwc5vjv/kRHB2h0Hvd1m69bHXKSEXPtwUHUG6hB8l8+/DXtU8TD0+NuBBjyd
Hr7EQxM6OUaRQF4ffBH3aguANV0ptUn31jVrqJVwPwaLXceaARv+ut2GpHm72VcmJ6
q4KPtMOr/f3C7QO6gofQeSSnEEbadVX9x+6rTuiBgQAOLq1P+eZkYM/kglTyj1aJn9
dZ5OMANWtbILRqi6bGfF6UTBbSHX9DMOJn7RGQB6JRZFx52kjGDm88+VKyQk4G0GcU
j91gxM3a7TCAw==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 2A3A4100035;
Mon, 19 Aug 2024 09:09:14 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 145541203FF;
Mon, 19 Aug 2024 09:09:14 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <jwvo76s5beg.fsf-monnier+@gnu.org> (Stefan Monnier's message of
"Sat, 20 Jul 2024 11:47:37 -0400")
Message-ID: <jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
Date: Mon, 19 Aug 2024 09:09:09 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.090 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
PROLO_LEO1 0.1 Meta Catches all Leo drug variations so far
T_SCC_BODY_TEXT_LINE -0.01 -
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
Wow, I did not expect such wild reactions!
Stefan
Stefan Monnier [2024-07-20 11:47:37] wrote:
> Package: Emacs
> Version: 31.0.50
>
>
> I think we should clean up our use of "condition objects", i.e. those
> objects created (internally) by `signal` and then passed back to ELisp
> via the VAR argument of `condition-case`.
>
> I manually re-ordered the patch so that it starts with `subr.el` where
> you can see the new definitions I suggest, and then the rest of the
> patch illustrates how they'd be used.
>
> The patch is not intended to be installed as-is because it changes some
> files which need to preserve backward compatibility with Emacsen without
> the new API.
>
> Also the patch lacks the "main" change which would be to replace the
> (almost 100) occurrences of
>
> (signal (car FOO) (cdr FOO))
>
> with
>
> (condition-resignal FOO)
>
> Beside whether we want to do this or not, there is another question
> about naming: currently we use "condition" in some places (e.g. in
> `condition-case`) but we use "error" in others (e.g. `define-error` and
> `error-message-string`). I chose to use "condition" in the patch below,
> but I don't have a strong opinion on that choice, so I could go with
> "error" if that's what other prefer. If we keep "condition" there's the
> subsidiary question whether we should add aliases for `define-error` and
> `error-message-string`.
>
>
> Stefan
>
>
> diff --git a/lisp/subr.el b/lisp/subr.el
> index 8c20fc5e9d4..cec6747dfcc 100644
> --- a/lisp/subr.el
> +++ b/lisp/subr.el
> @@ -503,6 +503,7 @@ user-error
> the `command-error-function' variable."
> (signal 'user-error (list (apply #'format-message format args))))
>
> +;; FIXME: Arguably, this should be called `define-condition'.
> (defun define-error (name message &optional parent)
> "Define NAME as a new error signal.
> MESSAGE is a string that will be output to the echo area if such an error
> @@ -523,6 +524,50 @@ define-error
> (delete-dups (copy-sequence (cons name conditions))))
> (when message (put name 'error-message message))))
>
> +(defun condition-resignal (condition)
> + "Re-signal the CONDITION.
> +CONDITION should be an object like those constructed by `signal' and
> +captured in the VAR of `condition-case'. This will signal the condition
> +again, like `signal' would do, but preserves the identity of CONDITION
> +instead of constructing a new object."
> + (unless (and (car-safe condition) (symbolp (car condition)))
> + (error "Not a condition object: %S" condition))
> + ;; `signal' happens to have an undocumented calling convention
> + ;; that does just what we need.
> + (signal condition nil))
> +
> +(defalias 'condition-type #'car
> + "Return the symbol which represents the type of CONDITION.
> +
> +(fn CONDITION)")
> +
> +(defalias 'condition-data #'cdr
> + "Return the slots attached to CONDITION, as a list.
> +
> +(fn CONDITION)")
> +
> +(defun condition-hastype-p (condition type)
> + "Return non-nil if CONDITION is of type TYPE (or a subtype of it)."
> + (memq type (get (car condition) 'error-conditions)))
> +
> +(defun condition-type-p (symbol)
> + "Return non-nil if SYMBOL is a condition type."
> + ;; FIXME: Should we also test `error-message'?
> + (get (car condition) 'error-conditions))
> +
> +(defun conditionp (object)
> + "Return non-nil if OBJECT is a condition."
> + (let ((type (car-safe object)))
> + (condition-type-p type)))
> +
> +(defalias 'condition-slot-value #'elt
> + "Access the SLOT of object CONDITION.
> +
> +(fn CONDITION SLOT)")
> +
> +;; FIXME: Make it more flexible!
> +(defalias 'condition-message-string #'error-message-string)
> +
> ;; We put this here instead of in frame.el so that it's defined even on
> ;; systems where frame.el isn't loaded.
> (defun frame-configuration-p (object)
> diff --git a/lisp/emacs-lisp/bytecomp.el b/lisp/emacs-lisp/bytecomp.el
> index 88167fc7ebd..e6578c8d42f 100644
> --- a/lisp/emacs-lisp/bytecomp.el
> +++ b/lisp/emacs-lisp/bytecomp.el
> @@ -4986,9 +4986,9 @@ byte-compile-condition-case
> (unless (and c (symbolp c))
> (byte-compile-warn-x
> c "`%S' is not a condition name (in condition-case)" c))
> - ;; In reality, the `error-conditions' property is only required
> + ;; In reality, the `error-conditions' property is required only
> ;; for the argument to `signal', not to `condition-case'.
> - ;;(unless (consp (get c 'error-conditions))
> + ;;(unless (condition-type-p c)
> ;; (byte-compile-warn
> ;; "`%s' is not a known condition name (in condition-case)"
> ;; c))
> @@ -5729,6 +5729,8 @@ batch-byte-compile-file
> (condition-case err
> (byte-compile-file file)
> (file-error
> + ;; FIXME: We should either `prin1' the whole ERR object
> + ;; or use `error-message-string' rather than this half-way thing.
> (message (if (cdr err)
> ">>Error occurred processing %s: %s (%s)"
> ">>Error occurred processing %s: %s")
> diff --git a/lisp/emacs-lisp/debug.el b/lisp/emacs-lisp/debug.el
> index ec947c1215d..08ecf50e82f 100644
> --- a/lisp/emacs-lisp/debug.el
> +++ b/lisp/emacs-lisp/debug.el
> @@ -563,9 +563,7 @@ debugger-eval-expression
> (condition-case err
> (backtrace-eval exp nframe base)
> (error (setq errored
> - (format "%s: %s"
> - (get (car err) 'error-message)
> - (car (cdr err)))))))))
> + (error-message-string err)))))))
> (if errored
> (progn
> (message "Error: %s" errored)
> diff --git a/lisp/emacs-lisp/edebug.el b/lisp/emacs-lisp/edebug.el
> index deebe5109bd..ebc33731b75 100644
> --- a/lisp/emacs-lisp/edebug.el
> +++ b/lisp/emacs-lisp/edebug.el
> @@ -3701,9 +3701,7 @@ edebug-safe-eval
> ;; If there is an error, a string is returned describing the error.
> (condition-case edebug-err
> (edebug-eval expr)
> - (error (edebug-format "%s: %s" ;; could
> - (get (car edebug-err) 'error-message)
> - (car (cdr edebug-err))))))
> + (error (error-message-string edebug-err))))
>
> ;;; Printing
>
> @@ -3711,14 +3709,7 @@ edebug-safe-eval
> (defun edebug-report-error (value)
> ;; Print an error message like command level does.
> ;; This also prints the error name if it has no error-message.
> - (message "%s: %s"
> - (or (get (car value) 'error-message)
> - (format "peculiar error (%s)" (car value)))
> - (mapconcat (lambda (edebug-arg)
> - ;; continuing after an error may
> - ;; complain about edebug-arg. why??
> - (prin1-to-string edebug-arg))
> - (cdr value) ", ")))
> + (message "%s" (error-message-string value)))
>
> ;; Alternatively, we could change the definition of
> ;; edebug-safe-prin1-to-string to only use these if defined.
> @@ -3767,10 +3758,7 @@ edebug-eval-expression
> (condition-case err
> (edebug-eval expr)
> (error
> - (setq errored
> - (format "%s: %s"
> - (get (car err) 'error-message)
> - (car (cdr err)))))))))
> + (setq errored (error-message-string err)))))))
> (result
> (unless errored
> (values--store-value value)
> diff --git a/lisp/emacs-lisp/elint.el b/lisp/emacs-lisp/elint.el
> index 27c169cc657..7d26346c6da 100644
> --- a/lisp/emacs-lisp/elint.el
> +++ b/lisp/emacs-lisp/elint.el
> @@ -146,6 +146,8 @@ elint-unknown-builtin-args
> "Those built-ins for which we can't find arguments, if any.")
>
> (defvar elint-extra-errors '(file-locked file-supersession ftp-error)
> + ;; FIXME: We should define these conditions properly to make
> + ;; `elint-extra-errors' obsolete.
> "Errors without `error-message' or `error-conditions' properties.")
>
> (defconst elint-preloaded-skip-re
> @@ -453,6 +456,7 @@ elint-init-form
> (setq elint-env (elint-env-add-macro elint-env (cadr form)
> (cons 'lambda (cddr form)))
> elint-env (elint-env-add-func elint-env (cadr form) (nth 2 form))))
> + ;; FIXME: Recognize `define-error' instead!
> ((and (eq (car form) 'put)
> (= 4 (length form))
> (eq (car-safe (cadr form)) 'quote)
> @@ -877,8 +881,7 @@ elint-check-condition-case-form
> (dolist (err (nthcdr 3 form))
> (setq errlist (car err))
> (mapc (lambda (s)
> - (or (get s 'error-conditions)
> - (get s 'error-message)
> + (or (condition-type-p s)
> (memq s elint-extra-errors)
> (elint-warning
> "Not an error symbol in error handler: %s" s)))
> diff --git a/lisp/emacs-lisp/ert.el b/lisp/emacs-lisp/ert.el
> index 6a665c8181d..81a7e8ca62e 100644
> --- a/lisp/emacs-lisp/ert.el
> +++ b/lisp/emacs-lisp/ert.el
> @@ -396,12 +396,12 @@ ert--should-error-handle-error
>
> Determines whether CONDITION matches TYPE and EXCLUDE-SUBTYPES,
> and aborts the current test as failed if it doesn't."
> - (let ((signaled-conditions (get (car condition) 'error-conditions))
> - (handled-conditions (pcase-exhaustive type
> + (let ((handled-conditions (pcase-exhaustive type
> ((pred listp) type)
> ((pred symbolp) (list type)))))
> - (cl-assert signaled-conditions)
> - (unless (cl-intersection signaled-conditions handled-conditions)
> + (cl-assert (conditionp condition))
> + (unless (cl-some (lambda (hc) (condition-hastype-p condition hc))
> + handled-conditions)
> (ert-fail (append
> (funcall form-description-fn)
> (list
> diff --git a/lisp/epa-file.el b/lisp/epa-file.el
> index 90cc91e99a0..7e1224e0c70 100644
> --- a/lisp/epa-file.el
> +++ b/lisp/epa-file.el
> @@ -117,10 +117,10 @@ epa-file--find-file-not-found-function
> (let ((error epa-file-error))
> (save-window-excursion
> (kill-buffer))
> - (if (nth 3 error)
> - (user-error "Wrong passphrase: %s" (nth 3 error))
> + (if (condition-slot-value error 3)
> + (user-error "Wrong passphrase: %s" (condition-slot-value error 3))
> (signal 'file-missing
> - (cons "Opening input file" (cdr error))))))
> + (cons "Opening input file" (condition-data error))))))
>
> (defun epa--wrong-password-p (context)
> "Return whether a wrong password caused the error in CONTEXT."
> @@ -171,23 +171,25 @@ epa-file-insert-file-contents
> ;; signal that as a non-file error
> ;; so that find-file-noselect-1 won't handle it.
> ;; Borrowed from jka-compr.el.
> - (if (and (memq 'file-error (get (car error) 'error-conditions))
> - (equal (cadr error) "Searching for program"))
> + (if (and (condition-hastype-p error 'file-error)
> + (equal (condition-slot-value error 1)
> + "Searching for program"))
> (error "Decryption program `%s' not found"
> - (nth 3 error)))
> + (condition-slot-value error 3)))
> (let ((exists (file-exists-p local-file)))
> (when exists
> (if-let ((wrong-password (epa--wrong-password-p context)))
> ;; Don't display the *error* buffer if we just
> ;; have a wrong password; let the later error
> ;; handler notify the user.
> - (setq error (append error (list wrong-password)))
> + (setf (cdr error) ;FIXME: `condition-data'!
> + (append (cdr error) (list wrong-password)))
> (epa-display-error context))
> ;; When the .gpg file isn't an encrypted file (e.g.,
> ;; it's a keyring.gpg file instead), then gpg will
> ;; say "Unexpected exit" as the error message. In
> ;; that case, just display the bytes.
> - (if (equal (caddr error) "Unexpected; Exit")
> + (if (equal (condition-slot-value error 2) "Unexpected; Exit")
> (setq string (with-temp-buffer
> (insert-file-contents-literally local-file)
> (buffer-string)))
> @@ -197,10 +199,10 @@ epa-file-insert-file-contents
> ;; `find-file-noselect-1'.
> (setq-local epa-file-error error)
> (add-hook 'find-file-not-found-functions
> - 'epa-file--find-file-not-found-function
> + #'epa-file--find-file-not-found-function
> nil t)))
> (signal (if exists 'file-error 'file-missing)
> - (cons "Opening input file" (cdr error))))))
> + (cons "Opening input file" (condition-data error))))))
> (set-buffer buf) ;In case timer/filter changed/killed it (bug#16029)!
> (setq-local epa-file-encrypt-to
> (mapcar #'car (epg-context-result-for
> diff --git a/lisp/jka-compr.el b/lisp/jka-compr.el
> index 0a14f0ab2b7..d0b75d7e3be 100644
> --- a/lisp/jka-compr.el
> +++ b/lisp/jka-compr.el
> @@ -471,22 +471,21 @@ jka-compr-insert-file-contents
> ;; If the file we wanted to uncompress does not exist,
> ;; handle that according to VISIT as `insert-file-contents'
> ;; would, maybe signaling the same error it normally would.
> - (if (and (eq (car error-code) 'file-missing)
> - (eq (nth 3 error-code) local-file))
> + (if (and (condition-hastype-p error-code 'file-missing)
> + (eq (condition-slot-value error-code 3) local-file))
> (if visit
> (setq notfound error-code)
> - (signal 'file-missing
> - (cons "Opening input file"
> - (nthcdr 2 error-code))))
> + (setf (condition-slot-value error-code 1)
> + "Opening input file")
> + (condition-resignal error-code))
> ;; If the uncompression program can't be found,
> ;; signal that as a non-file error
> ;; so that find-file-noselect-1 won't handle it.
> - (if (and (memq 'file-error (get (car error-code)
> - 'error-conditions))
> + (if (and (condition-hastype-p error-code 'file-error)
> (equal (cadr error-code) "Searching for program"))
> (error "Uncompression program `%s' not found"
> - (nth 3 error-code)))
> - (signal (car error-code) (cdr error-code)))))))
> + (nth 3 error-code))
> + (condition-resignal error-code)))))))
>
> (and
> local-copy
> diff --git a/lisp/net/sasl.el b/lisp/net/sasl.el
> index eb3d94475b9..79fabb42a0d 100644
> --- a/lisp/net/sasl.el
> +++ b/lisp/net/sasl.el
> @@ -50,8 +50,7 @@ sasl-mechanism-alist
>
> (defvar sasl-unique-id-function #'sasl-unique-id-function)
>
> -(put 'sasl-error 'error-message "SASL error")
> -(put 'sasl-error 'error-conditions '(sasl-error error))
> +(define-error 'sasl-error "SASL error")
>
> (defun sasl-error (datum)
> (signal 'sasl-error (list datum)))
> diff --git a/lisp/net/soap-client.el b/lisp/net/soap-client.el
> index de04d58ed18..41f9e254de2 100644
> --- a/lisp/net/soap-client.el
> +++ b/lisp/net/soap-client.el
> @@ -2886,7 +2886,7 @@ soap-decode-array
>
> ;;;; Soap Envelope parsing
>
> -(if (fboundp 'define-error)
> +(if (fboundp 'define-error) ;Emacs-24.4
> (define-error 'soap-error "SOAP error")
> ;; Support Emacs<24.4 that do not have define-error, so
> ;; that soap-client can remain unchanged in GNU ELPA.
> diff --git a/lisp/net/tramp-compat.el b/lisp/net/tramp-compat.el
> index 8781230c00c..4fae2ae73c0 100644
> --- a/lisp/net/tramp-compat.el
> +++ b/lisp/net/tramp-compat.el
> @@ -247,12 +247,12 @@ 'tramp-compat-always
>
> ;; `permission-denied' is introduced in Emacs 29.1.
> (defconst tramp-permission-denied
> - (if (get 'permission-denied 'error-conditions) 'permission-denied 'file-error)
> + (if (condition-type-p 'permission-denied) 'permission-denied 'file-error)
> "The error symbol for the `permission-denied' error.")
>
> (defsubst tramp-compat-permission-denied (vec file)
> "Emit the `permission-denied' error."
> - (if (get 'permission-denied 'error-conditions)
> + (if (condition-type-p 'permission-denied)
> (tramp-error vec tramp-permission-denied file)
> (tramp-error vec tramp-permission-denied "Permission denied: %s" file)))
>
> diff --git a/lisp/net/tramp-message.el b/lisp/net/tramp-message.el
> index 36079c8844c..de6ba65037c 100644
> --- a/lisp/net/tramp-message.el
> +++ b/lisp/net/tramp-message.el
> @@ -380,8 +380,12 @@ tramp-error
> vec-or-proc 1 "%s"
> (error-message-string
> (list signal
> + ;; FIXME: Looks redundant since `error-message-string'
> + ;; already uses the `error-message' property of `signal'!
> (get signal 'error-message)
> (apply #'format-message fmt-string arguments))))
> + ;; FIXME: This doesn't look right: ELisp code should be able to rely on
> + ;; the "shape" of the list based on the type of the signal.
> (signal signal (list (substring-no-properties
> (apply #'format-message fmt-string arguments))))))
>
> diff --git a/lisp/progmodes/elisp-mode.el b/lisp/progmodes/elisp-mode.el
> index 9bf6f9217c8..2e2da3ca103 100644
> --- a/lisp/progmodes/elisp-mode.el
> +++ b/lisp/progmodes/elisp-mode.el
> @@ -703,8 +703,7 @@ elisp-completion-at-point
> ;; specific completion table in more cases.
> (is-ignore-error
> (list t (elisp--completion-local-symbols)
> - :predicate (lambda (sym)
> - (get sym 'error-conditions))))
> + :predicate #'condition-type-p))
> ((elisp--expect-function-p beg)
> (list nil (elisp--completion-local-symbols)
> :predicate
> @@ -778,12 +777,11 @@ elisp-completion-at-point
> (forward-sexp 2)
> (< (point) beg)))))
> (list t (elisp--completion-local-symbols)
> - :predicate (lambda (sym) (get sym 'error-conditions))))
> + :predicate #'condition-type-p))
> ;; `ignore-error' with a list CONDITION parameter.
> ('ignore-error
> (list t (elisp--completion-local-symbols)
> - :predicate (lambda (sym)
> - (get sym 'error-conditions))))
> + :predicate #'condition-type-p))
> ((and (or ?\( 'let 'let*)
> (guard (save-excursion
> (goto-char (1- beg))
> diff --git a/lisp/simple.el b/lisp/simple.el
> index 5961afa20e9..28a6553892d 100644
> --- a/lisp/simple.el
> +++ b/lisp/simple.el
> @@ -3364,7 +3364,7 @@ minibuffer-error-function
> The same as `command-error-default-function' but display error messages
> at the end of the minibuffer using `minibuffer-message' to not obscure
> the minibuffer contents."
> - (if (memq 'minibuffer-quit (get (car data) 'error-conditions))
> + (if (condition-hastype-p data 'minibuffer-quit)
> (ding t)
> (discard-input)
> (ding))
> diff --git a/lisp/startup.el b/lisp/startup.el
> index f18795ae6ac..ee04f5ca3ae 100644
> --- a/lisp/startup.el
> +++ b/lisp/startup.el
> @@ -1124,15 +1124,12 @@ startup--load-user-init-file
> (display-warning
> 'initialization
> (format-message "\
> -An error occurred while loading `%s':\n\n%s%s%s\n\n\
> +An error occurred while loading `%s':\n\n%s\n\n\
> To ensure normal operation, you should investigate and remove the
> cause of the error in your initialization file. Start Emacs with
> the `--debug-init' option to view a complete error backtrace."
> user-init-file
> - (get (car error) 'error-message)
> - (if (cdr error) ": " "")
> - (mapconcat (lambda (s) (prin1-to-string s t))
> - (cdr error) ", "))
> + (error-message-string error))
> :warning)
> (setq init-file-had-error t))))))
>
> @@ -1431,15 +1428,12 @@ command-line
> (princ
> (if (eq (car error) 'error)
> (apply #'concat (cdr error))
> - (if (memq 'file-error (get (car error) 'error-conditions))
> + (if (condition-hastype-p error 'file-error)
> (format "%s: %s"
> (nth 1 error)
> (mapconcat (lambda (obj) (prin1-to-string obj t))
> (cdr (cdr error)) ", "))
> - (format "%s: %s"
> - (get (car error) 'error-message)
> - (mapconcat (lambda (obj) (prin1-to-string obj t))
> - (cdr error) ", "))))
> + (error-message-string error)))
> 'external-debugging-output)
> (terpri 'external-debugging-output)
> (setq initial-window-system nil)
> diff --git a/lisp/type-break.el b/lisp/type-break.el
> index 182f4656b16..bf32c69434e 100644
> --- a/lisp/type-break.el
> +++ b/lisp/type-break.el
> @@ -1025,7 +1025,7 @@ type-break-demo-life
> (setq continue nil)
> (and (get-buffer "*Life*")
> (kill-buffer "*Life*"))
> - (condition-case ()
> + (condition-case err
> (progn
> (life 3)
> ;; wait for user to return
> @@ -1033,7 +1033,7 @@ type-break-demo-life
> (type-break-catch-up-event)
> (kill-buffer "*Life*"))
> (life-extinct
> - (message "%s" (get 'life-extinct 'error-message))
> + (message "%s" (error-message-string err))
> ;; restart demo
> (setq continue t))
> (quit
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 15 Sep 2024 00:11:01 +0000
Resent-Message-ID: <handler.72212.B72212.17263590305665 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>, 72212 <at> debbugs.gnu.org
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.17263590305665
(code B ref 72212); Sun, 15 Sep 2024 00:11:01 +0000
Received: (at 72212) by debbugs.gnu.org; 15 Sep 2024 00:10:30 +0000
Received: from localhost ([127.0.0.1]:47993 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1spcqT-0001TI-OP
for submit <at> debbugs.gnu.org; Sat, 14 Sep 2024 20:10:30 -0400
Received: from mail-ed1-f54.google.com ([209.85.208.54]:42444)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stefankangas@HIDDEN>) id 1spcqR-0001T2-C5
for 72212 <at> debbugs.gnu.org; Sat, 14 Sep 2024 20:10:28 -0400
Received: by mail-ed1-f54.google.com with SMTP id
4fb4d7f45d1cf-5c40942358eso1659961a12.1
for <72212 <at> debbugs.gnu.org>; Sat, 14 Sep 2024 17:10:16 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1726358950; x=1726963750; darn=debbugs.gnu.org;
h=to:subject:message-id:date:mime-version:references:in-reply-to:from
:from:to:cc:subject:date:message-id:reply-to;
bh=AVhKphvsxAWH8yurrNxaL9FAX4Yzc9uc/3LDOqVjdHo=;
b=hyjuGp+7w/kzBWTFv1tcJ+3dGvdKe/7LtKXlDSEw1CmRK1/+eQxm9u0BXUzztK7JoP
ZRSXFFYWwp0ceq+Ct0e2geAs36K/TA0wV3ohTXbU/PMjXn4l29FVJjs2NfYDChOdPjea
ylIqQ5zchs/OOWWuIu3UvKfME27pCwS9rrMtuf9pb2IT/YJFHk2WI1i9Ps9k2KRjhF+K
jtVLpEc7K219ciEoFvFzVHVLMKvdQ8v6XQc311DJ4LOoTYV947DrjIWwZtHOw5LxbucT
mNISLxVkuPayQ8LC3diglCu3xpAVauUWK3AU3DrlcQh/50krERUJ82zeNHdZC2HvlA0R
NRXg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1726358950; x=1726963750;
h=to:subject:message-id:date:mime-version:references:in-reply-to:from
:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=AVhKphvsxAWH8yurrNxaL9FAX4Yzc9uc/3LDOqVjdHo=;
b=L37HwWkttFqHqTKLXzdY8hrPvBUtt5Xx76Ej/C7BsZYWgIN3o7w1pfhE/o1pWZAiaE
S5amg3PW/mdlKb66hiGV+iNMiWxhZdwMxX8PHVTZtob1e1jyB+hX561VGnxWTdZeeg51
sMRw98s/9BcKek4b62BJuym9bs18c+WuX9BHj+kow5R6FUkPmHymiEyYugGi1QrkpGOI
dg/van3Ujl+5exL6r4lXD4d1N+T6ohMoMyi8iM8V6Y8cAYq5lINe0StZdRIVwaOP6sXg
MezH2asPWH12ofNBEbR0EPAwTc/qLbN0w+mSoopcX6paWbc8wmAc9J8L94qw8IUyfj/K
+iKA==
X-Forwarded-Encrypted: i=1;
AJvYcCU80YnC/nu2nahdSR+Z2+lxqtrCubSc3AUOlEtucAVuPGTfmzARa9592eDZITMsDf8i9ge+Hg==@debbugs.gnu.org
X-Gm-Message-State: AOJu0Yw5Wqq+D0ZECG8+I8p+pZ3c25SLnWacuUe04KqPc1kMQ9b6vRfz
pwXUR1CiVpXeA0GmeW1QXxKe+dhRACypp7qeiTFSe2YmHjEjUE/MMjbfm/Heijk0vVt9Mi0i6vm
7l1uP0MJ8NeXOhr+JDtMGeOYDkVDCmlEX
X-Google-Smtp-Source: AGHT+IEFNxxsVGW1ek9SiNbjVMsV27XzWCOr+J3EiIJ2Nc1TbxZcO+7tDzLTgFovEPHMqW4Yl76vxLTiI8NAlcaKrbs=
X-Received: by 2002:a05:6402:27c7:b0:5c2:7699:92ef with SMTP id
4fb4d7f45d1cf-5c414387344mr12906094a12.16.1726358950184; Sat, 14 Sep 2024
17:09:10 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Sat, 14 Sep 2024 17:09:09 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
<jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Date: Sat, 14 Sep 2024 17:09:09 -0700
Message-ID: <CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs@HIDDEN> writes:
> Wow, I did not expect such wild reactions!
;-)
FWIW, your patch looks good to me, and seems like it's moving in a good
direction.
>> Beside whether we want to do this or not, there is another question
>> about naming: currently we use "condition" in some places (e.g. in
>> `condition-case`) but we use "error" in others (e.g. `define-error` and
>> `error-message-string`). I chose to use "condition" in the patch below,
>> but I don't have a strong opinion on that choice, so I could go with
>> "error" if that's what other prefer. If we keep "condition" there's the
>> subsidiary question whether we should add aliases for `define-error` and
>> `error-message-string`.
I think we should keep the word "condition", and think we could have
aliases "define-condition" and "condition-message-string" like you
propose.
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Tue, 17 Sep 2024 19:25:01 +0000
Resent-Message-ID: <handler.72212.B72212.172660107530848 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: 72212 <at> debbugs.gnu.org
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.172660107530848
(code B ref 72212); Tue, 17 Sep 2024 19:25:01 +0000
Received: (at 72212) by debbugs.gnu.org; 17 Sep 2024 19:24:35 +0000
Received: from localhost ([127.0.0.1]:56013 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1sqdoR-00081T-1Y
for submit <at> debbugs.gnu.org; Tue, 17 Sep 2024 15:24:35 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10249)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1sqdoP-00081C-Ay
for 72212 <at> debbugs.gnu.org; Tue, 17 Sep 2024 15:24:33 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 757F0100055;
Tue, 17 Sep 2024 15:24:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1726601047;
bh=F/YerRMGFPr3z/CX0brz5ApZsiw4kvrLc9SXR4C62RA=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=MFkrjur9Jvni8RrEM3yRNwlU0ES0g3O5tCQ7R1yHLZTYAnSdlGLjFg6TfyEXriMVA
FlP/bnVnO4LZLOnRRRUfp6ghPZDL8HsNpbKCoYT4+4mQcY8VdN8Payy465vtx8dHhj
h5oyOmu7y2HaKmHAGsEUJJBpPzZHCm1ehR0LeG8/TliUplqlwEnW1hRl+8QBdTCNi+
kppjLYr81mymr2WAyJNqzlBF9hg2lBH1r0ZFuOUb57u5Fc2k5SXW4LAz+XjEbZbiEd
TL9eNq36fROAk1l3A/RnK2n0aAgWhq38iXZ/U2YyAAzLmt0mw7QizR1G8I5BMJBAzL
tZUu1LeTvQBhQ==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 418E5100042;
Tue, 17 Sep 2024 15:24:07 -0400 (EDT)
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3277E120559;
Tue, 17 Sep 2024 15:24:07 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
(Stefan Kangas's message of "Sat, 14 Sep 2024 17:09:09 -0700")
Message-ID: <jwvtteegk4k.fsf-monnier+emacs@HIDDEN>
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
<jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
<CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
Date: Tue, 17 Sep 2024 15:24:06 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL 0.149 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> FWIW, your patch looks good to me, and seems like it's moving in a good
> direction.
Thanks.
> I think we should keep the word "condition", and think we could have
> aliases "define-condition" and "condition-message-string" like you
> propose.
OK, sounds good. I'll prepare a more complete patch.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 02 Nov 2024 19:39:01 +0000
Resent-Message-ID: <handler.72212.B72212.173057629724182 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Kangas <stefankangas@HIDDEN>
Cc: 72212 <at> debbugs.gnu.org
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.173057629724182
(code B ref 72212); Sat, 02 Nov 2024 19:39:01 +0000
Received: (at 72212) by debbugs.gnu.org; 2 Nov 2024 19:38:17 +0000
Received: from localhost ([127.0.0.1]:55241 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t7Jwv-0006Hy-AA
for submit <at> debbugs.gnu.org; Sat, 02 Nov 2024 15:38:17 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23368)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <monnier@HIDDEN>) id 1t7Jws-0006Ho-H4
for 72212 <at> debbugs.gnu.org; Sat, 02 Nov 2024 15:38:15 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 1B7BD80821;
Sat, 2 Nov 2024 15:38:08 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
s=mail; t=1730576286;
bh=xSxjc8yC+AE+gmMzDAYvJq59eDdNy/oosbxsRd0F2JQ=;
h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
b=QpBkaPlMDTKUXfMz7A+vpyxtdkjt3/A+ZhBY6rFMUr7G8WvUB3FrT8j7rl7uN2bhb
ooqCI/NlOxZbosFEvzeoUSUDB4eiol6rCdZHV5pt/jBHbcrHNR3xz+2daR/RFS6h01
PtOlSPNb5BYu5hIoctpzCwW42CuVj+IKhVtLsNl1Kob+i+qDG47csICVo11HIrVNI+
Aiz2OGPZWYKjMgdMcqig7eDljmZsKVXVAwCEinEC1CuSBbrt7A3Ui9yXH0WEy9fNcJ
FedtTZfvZfjAIIFDYiOgamw+Ar5EmGb6v14lmEp7IKxS8G9BWldj8JDKbx2Ct+sKI3
D/NDim6SmbvlA==
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DBA3C80024;
Sat, 2 Nov 2024 15:38:06 -0400 (EDT)
Received: from pastel (104-195-225-43.cpe.teksavvy.com [104.195.225.43])
by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id AEA6A12038D;
Sat, 2 Nov 2024 15:38:06 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
(Stefan Kangas's message of "Sat, 14 Sep 2024 17:09:09 -0700")
Message-ID: <jwvjzdlbfxg.fsf-monnier+emacs@HIDDEN>
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
<jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
<CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
Date: Sat, 02 Nov 2024 15:37:59 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results: 0
ALL_TRUSTED -1 Passed through trusted hosts only via SMTP
AWL -0.027 Adjusted score from AWL reputation of From: address
BAYES_00 -1.9 Bayes spam probability is 0 to 1%
DKIM_SIGNED 0.1 Message has a DKIM or DK signature,
not necessarily valid
DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
domain
DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
domain
X-SPAM-LEVEL:
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
>>> Beside whether we want to do this or not, there is another question
>>> about naming: currently we use "condition" in some places (e.g. in
>>> `condition-case`) but we use "error" in others (e.g. `define-error` and
>>> `error-message-string`).
> I think we should keep the word "condition", and think we could have
> aliases "define-condition" and "condition-message-string" like you
> propose.
From the code's point of view, this works OK, except I noticed that it
conflicts with the notion of "condition" used in the threading code (as
in `condition-wait`, `condition-variable-p`, ...), but on the manual
side it's quite a different story, because there we "systematically" use
the term "error", e.g.:
@node Errors
@subsection Errors
@cindex errors
When Emacs Lisp attempts to evaluate a form that, for some reason,
cannot be evaluated, it @dfn{signals} an @dfn{error}.
When an error is signaled, Emacs's default reaction is to print an
error message and terminate execution of the current command. This is
the right thing to do in most cases, such as if you type @kbd{C-f} at
the end of the buffer.
In complicated programs, simple termination may not be what you want.
For example, the program may have made temporary changes in data
structures, or created temporary buffers that should be deleted before
the program is finished. In such cases, you would use
@code{unwind-protect} to establish @dfn{cleanup expressions} to be
evaluated in case of error. (@xref{Cleanups}.) Occasionally, you may
wish the program to continue execution despite an error in a subroutine.
In these cases, you would use @code{condition-case} to establish
@dfn{error handlers} to recover control in case of error.
For reporting problems without terminating the execution of the
current command, consider issuing a warning instead. @xref{Warnings}.
Resist the temptation to use error handling to transfer control from
one part of the program to another; use @code{catch} and @code{throw}
instead. @xref{Catch and Throw}.
@menu
* Signaling Errors:: How to report an error.
* Processing of Errors:: What Emacs does when you report an error.
* Handling Errors:: How you can trap errors and continue execution.
* Error Symbols:: How errors are classified for trapping them.
@end menu
Here are options, I can see:
- Change the manual's text to use "condition" instead of "error" pretty
much everywhere.
- Use a naming based on `error` instead of `condition` (optionally with
`error-case(-unless-debug)` as aliases for `condition-case`?).
- Keep a mix, where we add to the manual a paragraph explaining that
`signal` really causes a "condition" but that most conditions (tho not
all, `quit` being the main(sole?) exception) are subtypes of the
`error` condition so we usually refer to conditions as "errors".
I'm leaning towards the third option, because I think straightening out
the mix of "conditions" and "errors" we have is fairly difficult.
Stefan
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 02 Nov 2024 19:50:02 +0000
Resent-Message-ID: <handler.72212.B72212.173057696725433 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 72212 <at> debbugs.gnu.org, stefankangas@HIDDEN
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.173057696725433
(code B ref 72212); Sat, 02 Nov 2024 19:50:02 +0000
Received: (at 72212) by debbugs.gnu.org; 2 Nov 2024 19:49:27 +0000
Received: from localhost ([127.0.0.1]:55297 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t7K7j-0006c9-1B
for submit <at> debbugs.gnu.org; Sat, 02 Nov 2024 15:49:27 -0400
Received: from eggs.gnu.org ([209.51.188.92]:52702)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <eliz@HIDDEN>) id 1t7K7g-0006c1-UI
for 72212 <at> debbugs.gnu.org; Sat, 02 Nov 2024 15:49:25 -0400
Received: from fencepost.gnu.org ([2001:470:142:3::e])
by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256)
(Exim 4.90_1) (envelope-from <eliz@HIDDEN>)
id 1t7K7a-0001Nu-ME; Sat, 02 Nov 2024 15:49:18 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date:
mime-version; bh=Dz7B53pPRWJuvy+IBH31cqcyOr0P6wkAkoDGPxEmz5I=; b=RqR9bQwESOyl
fKfi0FZ4RCai5p3PUvR9bxlSWbSbGxhQudVsnk6EW5sDP/NXCQb5wI+jWpLzphV2cCB4AGjyW+tNY
WJrsgcUrbfv307lKYpkiJ5vV2lCzRrxm1Oe85CsosejgEns5dG68GvL9z6/zcYhYvkFY0Lhnpn969
UmrwdkrnkhjflXjB1I8ssWQ+Wp+tppCwlq4Lcc9csU82rvHF8ydNow/NSII4HYIzfI/fuVLtfeGXc
gXW/luKgJ/3yFWzhh6Eu1tDMNtiDYtnKGX1fq2TH6ZOiWR2B2qdyS0AXufWX68/cOKOtMOIt4CTxX
ICCau7Ef13BQyPGoNXLBLg==;
Date: Sat, 02 Nov 2024 21:49:17 +0200
Message-Id: <861pztxvpe.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvjzdlbfxg.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
<jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
<CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
<jwvjzdlbfxg.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)
> Cc: 72212 <at> debbugs.gnu.org
> Date: Sat, 02 Nov 2024 15:37:59 -0400
> From: Stefan Monnier via "Bug reports for GNU Emacs,
> the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
>
> Here are options, I can see:
>
> - Change the manual's text to use "condition" instead of "error" pretty
> much everywhere.
> - Use a naming based on `error` instead of `condition` (optionally with
> `error-case(-unless-debug)` as aliases for `condition-case`?).
> - Keep a mix, where we add to the manual a paragraph explaining that
> `signal` really causes a "condition" but that most conditions (tho not
> all, `quit` being the main(sole?) exception) are subtypes of the
> `error` condition so we usually refer to conditions as "errors".
>
> I'm leaning towards the third option, because I think straightening out
> the mix of "conditions" and "errors" we have is fairly difficult.
Please don't rename "error" to something else. This new object type
can be called error-condition or something else, but please let's not
rename something so fundamental and basic in Emacs. It is unthinkable
that an obscure new feature will cause such a havoc in Emacs.
X-Loop: help-debbugs@HIDDEN
Subject: bug#72212: 31.0.50; API for condition objects
Resent-From: Stefan Kangas <stefankangas@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 02 Nov 2024 22:39:02 +0000
Resent-Message-ID: <handler.72212.B72212.173058709613760 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 72212
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords:
To: Stefan Monnier <monnier@HIDDEN>
Cc: 72212 <at> debbugs.gnu.org
Received: via spool by 72212-submit <at> debbugs.gnu.org id=B72212.173058709613760
(code B ref 72212); Sat, 02 Nov 2024 22:39:02 +0000
Received: (at 72212) by debbugs.gnu.org; 2 Nov 2024 22:38:16 +0000
Received: from localhost ([127.0.0.1]:56042 helo=debbugs.gnu.org)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
id 1t7Ml6-0003Zq-4C
for submit <at> debbugs.gnu.org; Sat, 02 Nov 2024 18:38:16 -0400
Received: from mail-ed1-f52.google.com ([209.85.208.52]:52541)
by debbugs.gnu.org with esmtp (Exim 4.84_2)
(envelope-from <stefankangas@HIDDEN>) id 1t7Ml3-0003Zk-Eh
for 72212 <at> debbugs.gnu.org; Sat, 02 Nov 2024 18:38:14 -0400
Received: by mail-ed1-f52.google.com with SMTP id
4fb4d7f45d1cf-5cb615671acso1863799a12.1
for <72212 <at> debbugs.gnu.org>; Sat, 02 Nov 2024 15:38:13 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=20230601; t=1730587032; x=1731191832; darn=debbugs.gnu.org;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:from:to:cc:subject:date:message-id:reply-to;
bh=0Yor/72u4o12Bg0RvsBu8hyv04sUiLAtSombiTqJGKU=;
b=D+Upd2mfbzNn3AUM8DAVQ1pV12T96gD6YcS2yUrbKaQY84empwG/OyI2StZYrN/HSJ
/IvBmVutz+ZIio6btdm3+81Hg9GTFtFAnyihmSL/ro0NFHufjNQTzRDFvTQQ2QcIOdrH
DKqMb/bmZ55VAG9Cfbdt8g3XB3tvSMzKCP8xr3wpN2JWHKXJCirpFGH57rlUjdygkZRm
5NftAs0uvxaMiCbIfdnntijBtj0exurC+IquLFBe9E/HdNqCvYJlhD0ZBYqQlgFNyV5s
jDuqhA7UMSbC5E6hI1atYodB15RwmoBtqcmv2XAsuQJa9dGdb8gXJmd3jt23NxC4yrz1
FiNg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=1e100.net; s=20230601; t=1730587032; x=1731191832;
h=cc:to:subject:message-id:date:mime-version:references:in-reply-to
:from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to;
bh=0Yor/72u4o12Bg0RvsBu8hyv04sUiLAtSombiTqJGKU=;
b=RqxQ4Si5hzZaTPWiRRhIzxyHNuIMA3iIx5vxl2fsRcq8N745dkMm9ChJwZNpRivoy3
7dnwoTmIVmAiAbfiylPfDrQ86OtppgWSne7zO6yn7Rx1K0/c+zcoSPG1KD2a1P0HbmDu
d4/v+xjcZx3/QBVG+CZJ+Duc+7/KALAzGemjHUNyZVYfrvkPi3xT3uXgk2Pst+JcWJor
+UEGyrNSTrbxKtXkhWQmIM4YcLu8uurVzUQBvMWtiklat55OsDcsT/I1W/hQCNFyUG86
vEl+4QXwMnM7zIhXhoD8yK5vJwCe2LRPDKWAZeRSRFYB2EcpaGi1NHHch/ut9AI/E0Hj
ReHQ==
X-Gm-Message-State: AOJu0Yxd6XZn4Dr+D0N/7/jAXh35Ci3cfi5SlDAkKVXKQtwzTRLcut87
XMW0mQHav6xRbGEhshWbTQEG6AnfA10+pELq0rkKI3pTA85sAgvhJLIeVhzb6hiSIGbMrX2xwsS
5aq1Mr25e6wZ4xmEypUEqnzKmcJM=
X-Google-Smtp-Source: AGHT+IHoERLhrAdiRJEDMbe7M792wUsdI36FkG/KulwvK/IULJhc2GXFFbx+eIfljJCzGc0hoLREVuVCKo1tvsZVGFc=
X-Received: by 2002:a05:6402:4308:b0:5c9:34b4:69a8 with SMTP id
4fb4d7f45d1cf-5ceb923ee52mr8533943a12.6.1730587032353; Sat, 02 Nov 2024
15:37:12 -0700 (PDT)
Received: from 753933720722 named unknown by gmailapi.google.com with
HTTPREST; Sat, 2 Nov 2024 15:37:11 -0700
From: Stefan Kangas <stefankangas@HIDDEN>
In-Reply-To: <jwvjzdlbfxg.fsf-monnier+emacs@HIDDEN>
References: <jwvo76s5beg.fsf-monnier+@gnu.org>
<jwvfrr0u0g1.fsf-monnier+emacs@HIDDEN>
<CADwFkmnPHMU=f3pq78f8Of=60y08Oinc9prxyrPUQ4FrTw4kVQ@HIDDEN>
<jwvjzdlbfxg.fsf-monnier+emacs@HIDDEN>
MIME-Version: 1.0
Date: Sat, 2 Nov 2024 15:37:11 -0700
Message-ID: <CADwFkmkcjAeV4+2UV-Ur-g-TyivrJ=AmaVqvZu_rHw+JaNCHNg@HIDDEN>
Content-Type: text/plain; charset="UTF-8"
X-Spam-Score: 0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>,
<mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.0 (-)
Stefan Monnier <monnier@HIDDEN> writes:
> Here are options, I can see:
>
> - Change the manual's text to use "condition" instead of "error" pretty
> much everywhere.
> - Use a naming based on `error` instead of `condition` (optionally with
> `error-case(-unless-debug)` as aliases for `condition-case`?).
> - Keep a mix, where we add to the manual a paragraph explaining that
> `signal` really causes a "condition" but that most conditions (tho not
> all, `quit` being the main(sole?) exception) are subtypes of the
> `error` condition so we usually refer to conditions as "errors".
>
> I'm leaning towards the third option, because I think straightening out
> the mix of "conditions" and "errors" we have is fairly difficult.
In an ideal world, we would perhaps take the plunge and rename "errors"
to "conditions", but that seems high-effort, and potentially painful and
controversial. It is not clear that it would be worth the effort.
At the same time, we could probably get 90 % of the way there with some
clarifications in our documentation. So, on balance, I agree that the
third option looks more attractive.
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997 nCipher Corporation Ltd,
1994-97 Ian Jackson.