From unknown Fri Jun 20 07:25:29 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#68075 <68075@debbugs.gnu.org> To: bug#68075 <68075@debbugs.gnu.org> Subject: Status: 30.0.50; New special form `handler-bind` Reply-To: bug#68075 <68075@debbugs.gnu.org> Date: Fri, 20 Jun 2025 14:25:29 +0000 retitle 68075 30.0.50; New special form `handler-bind` reassign 68075 emacs submitter 68075 Stefan Monnier severity 68075 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 01:33:35 2023 Received: (at submit) by debbugs.gnu.org; 28 Dec 2023 06:33:35 +0000 Received: from localhost ([127.0.0.1]:38287 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIjxX-0003Fj-0k for submit@debbugs.gnu.org; Thu, 28 Dec 2023 01:33:35 -0500 Received: from lists.gnu.org ([2001:470:142::17]:37256) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIjxU-0003FV-A3 for submit@debbugs.gnu.org; Thu, 28 Dec 2023 01:33:33 -0500 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 ) id 1rIjxP-0007Y3-Ie for bug-gnu-emacs@gnu.org; Thu, 28 Dec 2023 01:33:27 -0500 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 ) id 1rIjxN-0007TC-7l for bug-gnu-emacs@gnu.org; Thu, 28 Dec 2023 01:33:27 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DE05C1000EF for ; Thu, 28 Dec 2023 01:33:23 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703745202; bh=IpkX6U3Nj2n8gzvhj/3c0ZwZD+sbftFL3xd4KIkgJ9s=; h=From:To:Subject:Date:From; b=hEaDb2Ukvu+8Qp4Oa5K8H4f0zLLyoWf0FWIIkqFW4UHL7LBvptq14HAvM6esMF5Xg F7cXBXzID5Ze9ESHu+XmYC/loD3mlvsbPT9bjVBIAOOo1rcea7KMdP2klCB784/CL4 VspTtG3wDWSmnNV8tQ0SO6pY9qIxV5A5EQJrZp4CFW9a8kt5dnLc50fafkB8DKoat9 aRARn/Gg+xcwZPyKAMMiHVisDIiXN6zM2tIxZkwy3fRGf66cKePhDN9wWyAVwgDE9g HSbQ39LV8rzX2qtHV8J4YPw8cbSLf0rNy+kZ3AsUSGOVIw0Rxo5HwUH5OjL6bg0rhp 9Dp/ENHndq/Vg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 66372100054 for ; Thu, 28 Dec 2023 01:33:22 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 4A44D12050C for ; Thu, 28 Dec 2023 01:33:22 -0500 (EST) From: Stefan Monnier To: bug-gnu-emacs@gnu.org Subject: 30.0.50; New special form `handler-bind` X-Debbugs-Cc: monnier@iro.umontreal.ca Date: Thu, 28 Dec 2023 01:33:09 -0500 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.171 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 KAM_LOTSOFHASH 0.25 Emails with lots of hash-like gibberish T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; 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, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Package: Emacs Version: 30.0.50 I have now pushed to `scratch/handler-bind` a set of patches I'd like to commit to `master`. They add the new special form `handler-bind`, which provides a functionality a bit halfway between `condition-case` and `signal-hook-function`. Among other things, this allows us to fix bug#11218, bug#65267, and bug#67196. It also makes it possible to move code out of `signal_or_quit`. The complete log can be found below, but the oneliners are: New special form `handler-bind` (eval-expression): Fix bug#67196 ert.el: Use `handler-bind` to record backtraces Fix ert-tests.el for the new `handler-bind` code Use handler-bind to repair bytecomp-tests emacs-module-tests.el (mod-test-non-local-exit-signal-test): Repair test startup.el: Use `handler-bind` to implement `--debug-init` Move batch backtrace code to `top_level_2` (macroexp--with-extended-form-stack): Use plain `let` eval.c: Add new var `lisp-eval-depth-reserve` (signal_or_quit): Preserve error object identity (backtrace-on-redisplay-error): Use `handler-bind` As you can see, the first commit adds the new feature, and subsequent ones basically make use of it in various different places. Among those commits, I'll note the introduction of a new variable `lisp-eval-depth-reserve`, which lets us control how much Emacs can grow `max-lisp-eval-depth` to run the debugger. This is not indispensable, but seemed like a good idea. I also subtly changed the way errors are built such that we can rely on the error object being `eq` to itself as it moves up from the call to `signal` up to its `condition-case` handler, which should make it possible to keep extra info about it in an `eq` hashtable, for example. Comments, objections? Stefan commit a4efbe4c499623b33882a770c896ebfd31459ce9 Author: Stefan Monnier Date: Mon Dec 25 22:32:17 2023 -0500 New special form `handler-bind` =20=20=20=20 AFAIK, this provides the same semantics as Common Lisp's `handler-bind`, modulo the differences about how error objects and conditions are represented. =20=20=20=20 * lisp/subr.el (handler-bind): New macro. =20=20=20=20 * src/eval.c (pop_handler): New function. (Fhandler_Bind_1): New function. (signal_or_quit): Handle new handlertypes `HANDLER` and `SKIP_CONDITION= S`. (find_handler_clause): Simplify. (syms_of_eval): Defsubr `Fhandler_bind_1`. =20=20=20=20 * doc/lispref/control.texi (Handling Errors): Add `handler-bind`. =20=20=20=20 * test/src/eval-tests.el (eval-tests--handler-bind): New test. =20=20=20=20 * lisp/emacs-lisp/lisp-mode.el (lisp-font-lock-keywords): Move 'handler-bind' from CL-only to generic Lisp. (handler-bind): Remove indentation setting, it now lives in the macro definition. commit 19f1d2a9f5111a2f06003f45f3af2a39c7029047 Author: Stefan Monnier Date: Mon Dec 18 23:47:56 2023 -0500 (eval-expression): Fix bug#67196 =20=20=20=20 * lisp/simple.el (eval-expression--debug): New function. (eval-expression): Use it together with `handler-bind` instead of let-binding `debug-on-error`. commit ae21819496a7f003c4d4e185204533660197daaa Author: Stefan Monnier Date: Mon Dec 18 23:57:45 2023 -0500 ert.el: Use `handler-bind` to record backtraces =20=20=20=20 * lisp/emacs-lisp/ert.el (ert--should-signal-hook): Delete function. (ert--expand-should-1): Don't bind `signal-hook-function`. (ert--test-execution-info): Remove `next-debugger` slot. (ert--run-test-debugger): Adjust to new calling convention. Pass the `:backtrace-base` info to the debugger. (ert--run-test-internal): Use `handler-bind` rather than let-binding `debugger` and `debug-on-error`. =20=20=20=20 * lisp/emacs-lisp/ert-x.el (ert-remote-temporary-file-directory): Don't use `defconst` if it's not meant to stay constant (e.g. we let-bind it in tramp-tests.el). commit 89a298b3d2f86e75750617ef7e301372ea5aa46f Author: Stefan Monnier Date: Thu Dec 28 00:46:36 2023 -0500 Fix ert-tests.el for the new `handler-bind` code =20=20=20=20 Now that `ert.el` uses `handler-bind` instead of `debugger`, some details of the behavior have changed. More specifically, three tests are now broken, but these basically tested the failure of ERT's machinery to record errors when ERT was run within a `condition-case`. AFAICT, these tests do not check for a behavior that we want, so rather than "fix" them, I disabled them. =20=20=20=20 * test/lisp/emacs-lisp/ert-tests.el (ert-test-error-debug) (ert-test-fail-debug-with-condition-case) (ert-test-should-failure-debugging): Comment out. (ert-test-with-demoted-errors): It now passes. Bug#11218 is fixed! commit 1c1d2eb3e389bb5e397cd8e1568e4e3129067912 Author: Mattias Engdeg=E5rd Date: Wed Dec 27 11:32:49 2023 +0100 Use handler-bind to repair bytecomp-tests =20=20=20=20 * test/lisp/emacs-lisp/bytecomp-tests.el (bytecomp-tests--error-frame, bytecomp--byte-op-error-backtrace): Make test pass again and simplify, using handler-bind instead of the previous debugger hack. commit dcf7508c947359866151171a840d99d939c35cdf Author: Stefan Monnier Date: Thu Dec 28 00:49:39 2023 -0500 emacs-module-tests.el (mod-test-non-local-exit-signal-test): Repair test =20=20=20=20 That test relied on `debugger` and `debug-on-signal` in a way that doesn't work with the new ERT code. =20=20=20=20 * test/src/emacs-module-tests.el (mod-test-non-local-exit-signal-test): Use `handler-bind` rather than the debugger. commit 917596160c1c831b3a41b320a0e357e5161cb4c8 Author: Stefan Monnier Date: Tue Dec 19 19:46:47 2023 -0500 startup.el: Use `handler-bind` to implement `--debug-init` =20=20=20=20 This provides a more reliable fix for bug#65267 since we don't touch `debug-on-error` nor `debug-ignore-errors` any more. =20=20=20=20 * lisp/startup.el (startup--debug): New function. (startup--load-user-init-file): Use it and `handler-bind` instead of let-binding `debug-on-error`. commit 6a57b9151b149a445daecc211d8f58010e605768 Author: Stefan Monnier Date: Wed Dec 20 23:31:39 2023 -0500 Move batch backtrace code to `top_level_2` =20=20=20=20 Move ad-hoc code meant to ease debugging of bootstrap (and batch mode) to `top_level_2` so it doesn't pollute `signal_or_quit`. =20=20=20=20 * src/lisp.h (pop_handler, push_handler_bind): Declare. * src/keyboard.c (top_level_2): Setup an error handler to call `debug-early` when noninteractive. * src/eval.c (pop_handler): Not static any more. (signal_or_quit): Remove special case for noninteractive use. (push_handler_bind): New function, extracted from `Fhandler_bind_1`. (Fhandler_bind_1): Use it. (syms_of_eval): Declare `Qdebug_early__handler`. * lisp/emacs-lisp/debug-early.el (debug-early-backtrace): Weed out frames below `debug-early`. (debug-early--handler): New function. commit 634bf61947606d1b8344ba090fdd0fc098fb5eb6 Author: Stefan Monnier Date: Mon Dec 25 23:55:53 2023 -0500 (macroexp--with-extended-form-stack): Use plain `let` =20=20=20=20 `macroexp--with-extended-form-stack` used manual push/pop so that upon non-local exits the "deeper" value is kept, so the error handler gets to know what was the deeper value, so as to be able to compute more precise error locations. Replace this with a `handler-bind` which catches that "deeper" value more explicitly. =20=20=20=20 * lisp/emacs-lisp/bytecomp.el (bytecomp--displaying-warnings): Use `handler-bind` to catch the value of `byte-compile-form-stack` at the time of the error. Also consolidate the duplicated code. =20=20=20=20 * lisp/emacs-lisp/macroexp.el (macroexp--with-extended-form-stack): Use a plain dynbound let-rebinding. commit c89b234405f8fa6c52f83104a46a4a2c3121198f Author: Stefan Monnier Date: Tue Dec 26 23:56:09 2023 -0500 eval.c: Add new var `lisp-eval-depth-reserve` =20=20=20=20 Rather than blindly increase `max-lisp-eval-depth` when entering the debugger or running `signal-hook-function`, use this new "reserve" to keep track of how much we have grown the stack for "debugger" purposes so that for example recursive calls to `signal-hook-function` can't eat up the whole C stack. =20=20=20=20 * src/eval.c (max_ensure_room): Rewrite. (restore_stack_limits): Move before `max_ensure_room`. Rewrite. (call_debugger, signal_or_quit): Adjust calls accordingly. Also grow `max-lisp-eval-depth` for `hander-bind` handlers. (init_eval_once): Don't initialize `max_lisp_eval_depth` here. (syms_of_eval): Initialize it here instead. Add new var `lisp-eval-depth-reserve`. =20=20=20=20 * doc/lispref/eval.texi (Eval): Add `lisp-eval-depth-reserve`. commit b925152bffce30abbd48361af6858cd45b785d84 Author: Stefan Monnier Date: Wed Dec 27 15:06:32 2023 -0500 (signal_or_quit): Preserve error object identity =20=20=20=20 Make sure we build the (ERROR-SYMBOL . ERROR-DATA) object only once when signaling an error, so that its `eq` identity can be used. It also gets us a tiny bit closer to having real "error objects" like in most other current programming languages. =20=20=20=20 * src/eval.c (maybe_call_debugger): Change arglist to receive the error object instead of receiving the signal and the data separately. (signal_or_quit): Build the error object right at the beginning so it stays `eq` to itself. Rename the `keyboard_quit` arg to `continuable` so say what it does rather than what it's used for. (signal_quit_p): Change arg to be the error object rather than just the error-symbol. =20=20=20=20 * src/keyboard.c (cmd_error_internal, menu_item_eval_property_1): Adjust calls to `signal_quit_p` accordingly. =20=20=20=20 * test/src/eval-tests.el (eval-tests--error-id): New test. commit 26b7078705ae5b9226c99e370740ab9a4063f20f Author: Stefan Monnier Date: Mon Dec 25 21:41:08 2023 -0500 (backtrace-on-redisplay-error): Use `handler-bind` =20=20=20=20 Reimplement `backtrace-on-redisplay-error` using `push_handler_bind`. This moves the code from `signal_or_quit` to `xdisp.c` and `debug-early.el`. =20=20=20=20 * lisp/emacs-lisp/debug-early.el (debug-early-backtrace): Add `base` arg to strip "internal" frames. (debug--early): New function, extracted from `debug-early`. (debug-early, debug-early--handler): Use it. (debug-early--muted): New function, extracted (translated) from `signal_or_quit`; trim the buffer to a max of 10 backtraces. =20=20=20=20 * src/xdisp.c (funcall_with_backtraces): New function. (dsafe_calln): Use it. (syms_of_xdisp): Defsym `Qdebug_early__muted`. =20=20=20=20 * src/eval.c (redisplay_deep_handler): Delete var. (init_eval, internal_condition_case_n): Don't set it any more. (backtrace_yet): Delete var. (signal_or_quit): Remove special case for `backtrace_on_redisplay_error= `. * src/keyboard.c (command_loop_1): Don't set `backtrace_yet` any more. * src/lisp.h (backtrace_yet): Don't declare. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 03:03:40 2023 Received: (at 68075) by debbugs.gnu.org; 28 Dec 2023 08:03:41 +0000 Received: from localhost ([127.0.0.1]:38358 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIlMi-0004O5-3K for submit@debbugs.gnu.org; Thu, 28 Dec 2023 03:03:40 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:44366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIlMg-0004Ns-54 for 68075@debbugs.gnu.org; Thu, 28 Dec 2023 03:03:39 -0500 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 ) id 1rIlMa-0001f7-8Q; Thu, 28 Dec 2023 03:03:32 -0500 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=G3poZ8LlkoI2xGAc8fdjCFt2brITKIVdGWvx+7v8a1g=; b=qh9QZlSiv3nl AqBw81yl/1tW/Ms9gWIWGcLOJ3KalSoI2PNa3obI4RrTyJkzAIvkqTfU2ByqHAuH5TKOmZe0GIBlI 84mUxePrXi6y5AyGimfmztxC7k2bTaZOXuHlQki7nkOmdrJE4VyCMglomKx/hO69Fu4PYITSCxLc/ G2N034R8q4Oz70+uiF2Hp1AFkH/rZpTzbyPzBYIDWfB6tDja88fd1ndqfi316nEE+LMFNH8TQqCh9 v2IskpxoWkmhmrudUuryJiKcwHSro4l6jsfYH11MLejxBSjZ6dGS0QKh/Q+kSgE5AG4DkbMvjNf8b iL2ek9+ayVjpM1L6eD3uKQ==; Date: Thu, 28 Dec 2023 10:03:16 +0200 Message-Id: <835y0i92kb.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (bug-gnu-emacs@gnu.org) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: monnier@iro.umontreal.ca > Date: Thu, 28 Dec 2023 01:33:09 -0500 > From: Stefan Monnier via "Bug reports for GNU Emacs, > the Swiss army knife of text editors" > > I have now pushed to `scratch/handler-bind` a set of patches I'd like to > commit to `master`. They add the new special form `handler-bind`, which > provides a functionality a bit halfway between `condition-case` and > `signal-hook-function`. > > Among other things, this allows us to fix bug#11218, bug#65267, and > bug#67196. It also makes it possible to move code out of > `signal_or_quit`. > > The complete log can be found below, but the oneliners are: > > New special form `handler-bind` > (eval-expression): Fix bug#67196 > ert.el: Use `handler-bind` to record backtraces > Fix ert-tests.el for the new `handler-bind` code > Use handler-bind to repair bytecomp-tests > emacs-module-tests.el (mod-test-non-local-exit-signal-test): Repair test > startup.el: Use `handler-bind` to implement `--debug-init` > Move batch backtrace code to `top_level_2` > (macroexp--with-extended-form-stack): Use plain `let` > eval.c: Add new var `lisp-eval-depth-reserve` > (signal_or_quit): Preserve error object identity > (backtrace-on-redisplay-error): Use `handler-bind` > > As you can see, the first commit adds the new feature, and subsequent > ones basically make use of it in various different places. > > Among those commits, I'll note the introduction of a new variable > `lisp-eval-depth-reserve`, which lets us control how much Emacs can grow > `max-lisp-eval-depth` to run the debugger. This is not indispensable, > but seemed like a good idea. I also subtly changed the way errors > are built such that we can rely on the error object being `eq` to itself > as it moves up from the call to `signal` up to its `condition-case` > handler, which should make it possible to keep extra info about it > in an `eq` hashtable, for example. > > Comments, objections? Assuming by the above you meant that the branch is from your POV ready to land on master, please find some review comments below. > diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi > index d4bd8c1..4107963 100644 > --- a/doc/lispref/control.texi > +++ b/doc/lispref/control.texi > @@ -2293,6 +2293,44 @@ Handling Errors > @code{condition-case-unless-debug} rather than @code{condition-case}. > @end defmac > > +Occasionally, we want to catch some errors and record some information > +about the conditions in which they occurred, such as the full > +backtrace, or the current buffer. This kinds of information is sadly > +not available in the handlers of a @code{condition-case} because the > +stack is unwound before running that handler, so the handler is run in > +the dynamic context of the @code{condition-case} rather than that of > +the place where the error was signaled. For those circumstances, you > +can use the following form: The reference to "unwinding the stack before running handler" uses terminology and assumes knowledge we don't generally expect from readers of the ELisp manual. This should be reworded to use the terminology we use in other cases where we talk about "unwinding" and error handlers. > +@defmac handler-bind handlers body@dots{} > +This special form runs @var{body} and if it executes without error, > +the value it returns becomes the value of the @code{handler-bind} > +form. In this case, the @code{handler-bind} has no effect. > + > +@var{handlers} should be a list of elements of the form > +@code{(@var{conditions} @var{handler})} where @var{conditions} is an > +error condition name to be handled, or a list of condition names, and > +@var{handler} should be a form whose evaluation should return a function. CONDITIONs are symbols, aren't they? The above says "condition names", which could be interpreted as if they were strings instead. > +Before running @var{body}, @code{handler-bind} evaluates all the > +@var{handler} forms and installs those handlers to be active during > +the evaluation of @var{body}. These handlers are searched together > +with those installed by @code{condition-case}. This reference to condition-case might confuse: what does condition-case have to do with handler-bind? And if it is expected that handler-bind is used inside condition-case, there should be some text about it, and the examples we hopefully add should illustrate that. > When the innermost > +matching handler is one installed by @code{handler-bind}, the > +@var{handler} function is called with a single argument holding the > +error description. Is "error description" the same as "error name" above? If so, let's please use consistent wording to minimize the chances for confusion and misunderstandings. > +@var{handler} is called in the dynamic context where the error > +happened, without first unwinding the stack, meaning that all the > +dynamic bindings are still in effect, Should we tell something about the effects of lexical-binding on those "dynamic bindings"? > except that all the error > +handlers between the code that signaled the error and the > +@code{handler-bind} are temporarily suspended. Not sure I understand what it means for those handlers to be "suspended". can the text say more about that? > Like any normal > +function, @var{handler} can exit non-locally, typically via > +@code{throw}, or it can return normally. If @var{handler} returns > +normally, it means the handler @emph{declined} to handle the error and > +the search for an error handler is continued where it left off. > +@end defmac I think we should have a couple of examples here, to show the utility of handler-bind and how it is different from condition-case. > +@defopt lisp-eval-depth-reserve > +In order to be able to debug infinite recursion errors, Entry to the ^^^ Typo. > +Lisp debugger increases temporarily the value of > +@code{max-lisp-eval-depth}, if there is little room left, to make sure > +the debugger itself has room to execute. The same happens when > +running the handler of a @code{handler-bind}. Please add here a cross-reference to where handler-bind is documented. > +The variable @code{lisp-eval-depth-reserve} bounds the extra depth > +that Emacs can add to @code{max-lisp-eval-depth} for those > +exceptional circumstances. > +@end defopt I think this should document the default value. > ++++ > +** New special form 'handler-bind'. > +Provides a functionality similar to `condition-case` except it runs the > +handler code without unwinding the stack, such that we can record the > +backtrace and other dynamic state at the point of the error. Please add here a link to the node in the ELisp manual where handler-bind is described. > -(defmacro displaying-byte-compile-warnings (&rest body) > +(defmacro displaying-byte-compile-warnings (&rest body) ;FIXME: Namespace! ^^^^^^^^^^^^^^^^^^ What about this FIXME? > +(defmacro handler-bind (handlers &rest body) > + "Setup error HANDLERS around execution of BODY. > +HANDLERS is a list of (CONDITIONS HANDLER) where > +CONDITIONS should be a list of condition names (symbols) or > +a single condition name and HANDLER is a form whose evaluation ^ A comma is missing there. > +returns a function. > +When an error is signaled during execution of BODY, if that > +error matches CONDITIONS, then the associated HANDLER > +function is called with the error as argument. ^^^^^^^^^^^^^^^^^^^^^^^^^^ "Error" or "condition name"? If "error", then what does "error matches CONDITIONS" mean in practice? > +HANDLERs can either transfer the control via a non-local exit, > +or return normally. If they return normally the search for an ^^^^^^^^^^^^^^ I'd suggest "If a handler returns" instead. There's just one HANDLER involved here, right? > +error handler continues from where it left off." This "from where it left off" sounds confusing: what does it mean? IOW, how is it different from saying If a HANDLER returns normally, other CONDITIONS are searched for a match, and, if found, their HANDLERs are called. Btw, this begs the question: what happens if none of the CONDITIONS match? In particular, what happens if a HANDLER is called, returns normally, and none of the other CONDITIONS match? > + ;; FIXME: Completion support as in `condition-case'? ^^^^^ What about this FIXME? > @@ -317,6 +312,7 @@ call_debugger (Lisp_Object arg) > /* Interrupting redisplay and resuming it later is not safe under > all circumstances. So, when the debugger returns, abort the > interrupted redisplay by going back to the top-level. */ > + /* FIXME: Move this to the redisplay code? */ ^^^^^ And this one? > +DEFUN ("handler-bind-1", Fhandler_bind_1, Shandler_bind_1, 1, MANY, 0, > + doc: /* Setup error handlers around execution of BODYFUN. > +BODYFUN be a function and it is called with no arguments. > +CONDITIONS should be a list of condition names (symbols). > +When an error is signaled during executon of BODYFUN, if that > +error matches one of CONDITIONS, then the associated HANDLER is > +called with the error as argument. > +HANDLER should either transfer the control via a non-local exit, > +or return normally. > +If it returns normally, the search for an error handler continues > +from where it left off. "Where it left off" strikes again... > + specpdl_ref count = SPECPDL_INDEX (); > + max_ensure_room (20); > + /* FIXME: 'handler-bind' makes `signal-hook-function' obsolete? */ > + /* FIXME: Here we still "split" the error object > + into its error-symbol and its error-data? */ > call2 (Vsignal_hook_function, error_symbol, data); > + unbind_to (count, Qnil); FIXMEs again. > top_level_2 (void) > { > - return Feval (Vtop_level, Qnil); > + /* If we're in batch mode, print a backtrace unconditionally when > + encountering an error, to help with debugging. */ > + bool setup_handler = noninteractive; > + if (setup_handler) > + /* FIXME: Should we (re)use `list_of_error` from `xdisp.c`? */ > + push_handler_bind (list1 (Qerror), Qdebug_early__handler, 0); And again. > +;; (ert-deftest ert-test-fail-debug-with-condition-case () > +;; (let ((test (make-ert-test :body (lambda () (ert-fail "failure message"))))) > +;; (condition-case condition > +;; (progn > +;; (let ((ert-debug-on-error t)) > +;; (ert-run-test test)) > +;; (cl-assert nil)) > +;; ((error) > +;; (cl-assert (equal condition '(ert-test-failed "failure message")) t))))) What about this and other places where some code was commented-out, but not removed? Those seem to be tests that you disable - why? Are they no longer pertinent, or do they fail for some reason that should be fixed? Last, but not least: do all the tests in the test suite pass after these changes, both with and without native-compilation? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 13:12:30 2023 Received: (at 68075) by debbugs.gnu.org; 28 Dec 2023 18:12:30 +0000 Received: from localhost ([127.0.0.1]:40317 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIurt-0007Yg-8f for submit@debbugs.gnu.org; Thu, 28 Dec 2023 13:12:30 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:25513) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIurp-0007YP-6y for 68075@debbugs.gnu.org; Thu, 28 Dec 2023 13:12:27 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7B81A831F3; Thu, 28 Dec 2023 13:12:19 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703787133; bh=BpfdZMzHDNPSwo8tApFUo3WYtzKvO7qd/Kn90N0zXq4=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=QLZ4R5Fy7bKf5C/a3BJfyqiuHLWzreWG1xFWtFBwslh8c/q1WY69OSa5S1lgH2Yn1 8JWTTO+qOVw+CBirMldBQcoOEIsPy9KczzuJgIRJHO3PrzM9FaD7l+uDOrbbu3GqtN Hv3lDDp3oBG6LTBecTevTsXTm/vu9Qcht0eYBXbrlRVf9TSs1bPS0c3CCipPXBrLuU oVQBLBwz2xvVLBw2i1Pi58Rny4KYgxjAonzhVOUpYMXZqzW0QOz9fT6cMT0L1ZGkeo imqz9jr92G7tcGwCqSyzsSBk8Z6Wpq8lOmZWTbZ/MkfOibFbRo7QdYMOVLWVXPlXKE tI2r9Fp89DxOw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 83BE980C88; Thu, 28 Dec 2023 13:12:13 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5B0E112110F; Thu, 28 Dec 2023 13:12:13 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <835y0i92kb.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 28 Dec 2023 10:03:16 +0200") Message-ID: References: <835y0i92kb.fsf@gnu.org> Date: Thu, 28 Dec 2023 13:12:12 -0500 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.052 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Comments, objections? > > Assuming by the above you meant that the branch is from your POV ready > to land on master, > please find some review comments below. That's right (tho I did expect that the doc needed some improvement :-) > The reference to "unwinding the stack before running handler" uses > terminology and assumes knowledge we don't generally expect from > readers of the ELisp manual. This should be reworded to use the > terminology we use in other cases where we talk about "unwinding" and > error handlers. See patch below for my attempt to clarify. >> +@var{handlers} should be a list of elements of the form >> +@code{(@var{conditions} @var{handler})} where @var{conditions} is an >> +error condition name to be handled, or a list of condition names, and >> +@var{handler} should be a form whose evaluation should return a function. > > CONDITIONs are symbols, aren't they? The above says "condition > names", which could be interpreted as if they were strings instead. I took this nomenclature from `condition-case` where we say: [...] Here @var{conditions} is an error condition name to be handled, or a list of condition names (which can include @code{debug} to allow the debugger to run before the handler). I added a mention that these names are symbols. >> +Before running @var{body}, @code{handler-bind} evaluates all the >> +@var{handler} forms and installs those handlers to be active during >> +the evaluation of @var{body}. These handlers are searched together >> +with those installed by @code{condition-case}. > > This reference to condition-case might confuse: what does > condition-case have to do with handler-bind? I'm trying to explain that when looking for a handler, we look both for condition-case handler and handler-bind handlers and we use whichever is "closest", i.e. more deeply nested. So just like a local `condition-case` overrides temporarily an outer one, the same holds not only among `handler-bind`s but also between `condition-case` and `handler-bind` as well. See the patch for my attempt to clarify. >> When the innermost >> +matching handler is one installed by @code{handler-bind}, the >> +@var{handler} function is called with a single argument holding the >> +error description. > > Is "error description" the same as "error name" above? No, it's I like to call the error object: @cindex error description The argument @var{var} is a variable. @code{condition-case} does not bind this variable when executing the @var{protected-form}, only when it handles an error. At that time, it binds @var{var} locally to an @dfn{error description}, which is a list giving the particulars of the error. The error description has the form @code{(@var{error-symbol} . @var{data})}. The handler can refer to this list to decide what to do. For example, if the error is for failure opening a file, the file name is the second element of @var{data}---the third element of the error description. > If so, let's please use consistent wording to minimize the chances for > confusion and misunderstandings. I wasn't familiar with the term "error description" either, but that's apparently what we use in the Texinfo doc, so I used it specifically to try and "use consistent wording" :-) >> +@var{handler} is called in the dynamic context where the error >> +happened, without first unwinding the stack, meaning that all the >> +dynamic bindings are still in effect, > > Should we tell something about the effects of lexical-binding on those > "dynamic bindings"? It's not related to `handler-bind` in any case, so if we want to say something about it, we should do it elsewhere (and I think we already do when we discuss lexical binding). >> except that all the error >> +handlers between the code that signaled the error and the >> +@code{handler-bind} are temporarily suspended. > Not sure I understand what it means for those handlers to be > "suspended". can the text say more about that? Indeed, it's a delicate part of he semantics (the one that introduces the need for the SKIP_CONDITIONS thingy in the C code). Let me know how you like the new text below. > I think we should have a couple of examples here, to show the utility > of handler-bind and how it is different from condition-case. I added two examples. >> +@defopt lisp-eval-depth-reserve >> +In order to be able to debug infinite recursion errors, Entry to the > ^^^ > Typo. Hmm... yes that's not right, thanks. >> +The variable @code{lisp-eval-depth-reserve} bounds the extra depth >> +that Emacs can add to @code{max-lisp-eval-depth} for those >> +exceptional circumstances. >> +@end defopt > I think this should document the default value. OK. >> ++++ >> +** New special form 'handler-bind'. >> +Provides a functionality similar to `condition-case` except it runs the >> +handler code without unwinding the stack, such that we can record the >> +backtrace and other dynamic state at the point of the error. > > Please add here a link to the node in the ELisp manual where > handler-bind is described. OK. >> -(defmacro displaying-byte-compile-warnings (&rest body) >> +(defmacro displaying-byte-compile-warnings (&rest body) ;FIXME: Namespace! > ^^^^^^^^^^^^^^^^^^ > What about this FIXME? Just a namespace uncleanliness I noticed when working on this code. >> +(defmacro handler-bind (handlers &rest body) >> + "Setup error HANDLERS around execution of BODY. >> +HANDLERS is a list of (CONDITIONS HANDLER) where >> +CONDITIONS should be a list of condition names (symbols) or >> +a single condition name and HANDLER is a form whose evaluation > ^ > A comma is missing there. Thanks. >> +returns a function. >> +When an error is signaled during execution of BODY, if that >> +error matches CONDITIONS, then the associated HANDLER >> +function is called with the error as argument. > ^^^^^^^^^^^^^^^^^^^^^^^^^^ > "Error" or "condition name"? The actual error object (aka "error description"). > If "error", then what does "error matches CONDITIONS" mean > in practice? It means that the "type" or "error name" of the error if a "subtype" of one of CONDITIONS. Given that we represent errors as (ERROR-NAME . ERROR-DATA) rather than as objects, the "type" of an error is just the ERROR-NAME symbol. And the "subtyping" relation is defined by the `parent` arg to `define-error`. This is exactly the same as for `condition-case`, of course. >> +HANDLERs can either transfer the control via a non-local exit, >> +or return normally. If they return normally the search for an > ^^^^^^^^^^^^^^ > I'd suggest "If a handler returns" instead. There's just one > HANDLER involved here, right? Thanks, yes. >> +error handler continues from where it left off." > > This "from where it left off" sounds confusing: what does it mean? > IOW, how is it different from saying > > If a HANDLER returns normally, other CONDITIONS are searched for a > match, and, if found, their HANDLERs are called. > > Btw, this begs the question: what happens if none of the CONDITIONS > match? In particular, what happens if a HANDLER is called, returns > normally, and none of the other CONDITIONS match? Same as for `condition-case`, we keep searching in surrounding handlers. Not sure how to say it more clearly without becoming too verbose for a docstring. That's what the Texinfo doc is for, no? >> + ;; FIXME: Completion support as in `condition-case'? > ^^^^^ > What about this FIXME? Haven't implemented that yet. `handler-bind` is not going to be used nearly as often as `condition-case`, but I don't think it's very high priority to implement this feature. [ A more important completion feature in this area would be to complete the name of existing generic functions after `cl-defmethod` :-) ] >> @@ -317,6 +312,7 @@ call_debugger (Lisp_Object arg) >> /* Interrupting redisplay and resuming it later is not safe under >> all circumstances. So, when the debugger returns, abort the >> interrupted redisplay by going back to the top-level. */ >> + /* FIXME: Move this to the redisplay code? */ > ^^^^^ > And this one? That's the "redisplay_counter" patch we discussed elsewhere. I have it in the `scratch/handler-bind-2` branch, but it's not really related to `handler-bind`. >> +DEFUN ("handler-bind-1", Fhandler_bind_1, Shandler_bind_1, 1, MANY, 0, >> + doc: /* Setup error handlers around execution of BODYFUN. >> +BODYFUN be a function and it is called with no arguments. >> +CONDITIONS should be a list of condition names (symbols). >> +When an error is signaled during executon of BODYFUN, if that >> +error matches one of CONDITIONS, then the associated HANDLER is >> +called with the error as argument. >> +HANDLER should either transfer the control via a non-local exit, >> +or return normally. >> +If it returns normally, the search for an error handler continues >> +from where it left off. > "Where it left off" strikes again... Of course :-) >> + specpdl_ref count = SPECPDL_INDEX (); >> + max_ensure_room (20); >> + /* FIXME: 'handler-bind' makes `signal-hook-function' obsolete? */ >> + /* FIXME: Here we still "split" the error object >> + into its error-symbol and its error-data? */ >> call2 (Vsignal_hook_function, error_symbol, data); >> + unbind_to (count, Qnil); > > FIXMEs again. Yup. For the first, I'm not yet sure if it really makes `signal-hook-function` obsolete (I have PoC patches on `handler-bind-2` to remove existing uses, but I'm not sure these DTRT). For the second, it's an API problem we can't really fix without breaking backward compatibility. If we're lucky, we can declare `signal-hook-function` obsolete and those problems will disappear. >> top_level_2 (void) >> { >> - return Feval (Vtop_level, Qnil); >> + /* If we're in batch mode, print a backtrace unconditionally when >> + encountering an error, to help with debugging. */ >> + bool setup_handler = noninteractive; >> + if (setup_handler) >> + /* FIXME: Should we (re)use `list_of_error` from `xdisp.c`? */ >> + push_handler_bind (list1 (Qerror), Qdebug_early__handler, 0); > > And again. Here, I'm really asking reviewers whether they think we should use `list_of_error` here (which would require making it non-static and declaring it in `lisp.h` or somesuch). >> +;; (ert-deftest ert-test-fail-debug-with-condition-case () >> +;; (let ((test (make-ert-test :body (lambda () (ert-fail "failure message"))))) >> +;; (condition-case condition >> +;; (progn >> +;; (let ((ert-debug-on-error t)) >> +;; (ert-run-test test)) >> +;; (cl-assert nil)) >> +;; ((error) >> +;; (cl-assert (equal condition '(ert-test-failed "failure message")) t))))) > > What about this and other places where some code was commented-out, > but not removed? Those seem to be tests that you disable - why? The commit message explains it: Now that `ert.el` uses `handler-bind` instead of `debugger`, some details of the behavior have changed. More specifically, three tests are now broken, but these basically tested the failure of ERT's machinery to record errors when ERT was run within a `condition-case`. AFAICT, these tests do not check for a behavior that we want, so rather than "fix" them, I disabled them. Maybe I should delete them rather than comment them out? I guess I could also keep them commented out but with the above commit message turned into a comment, but in that case I have to move those 3 tests so they can be together next to the new comment. Either way works for me. > Last, but not least: do all the tests in the test suite pass after > these changes, both with and without native-compilation? Yup. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 13:14:36 2023 Received: (at 68075) by debbugs.gnu.org; 28 Dec 2023 18:14:36 +0000 Received: from localhost ([127.0.0.1]:40322 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIutw-0007c6-7Z for submit@debbugs.gnu.org; Thu, 28 Dec 2023 13:14:36 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7660) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIutt-0007bs-39 for 68075@debbugs.gnu.org; Thu, 28 Dec 2023 13:14:35 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 408F683174; Thu, 28 Dec 2023 13:14:28 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703787266; bh=BCYphzUZjREccasqAgkFowfbN9R4gebyTve99RyIMwU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=AqxCh9Ipe2uHOf6BKxmDr59N3BYsIlTNlUBh8OKd3MbMngbMGpewKC3H/8KkG0WAR TfnIPxF7C/aChzksRayZfx8Kd2T87dL4/kFp88cpYqo6mIdPFfooKbIyXK2oHeAqTY yOEYB6/37wq8KsPmhRHUi293fXK8KLjMIr8UlD4T1yLj65hzLsluCqcqyyjHLq6DVY 6VwbXahpEUIOD3F/N9fkzY9XGJ10rh+6ng0al4pYwhq3sT1xgQkvg8IwJZyKaXauT4 mgksggv7oua6n3AqQtC/YSpYQIiJ3uq+fMeiVFuz+GSaMjzbj6K+TDwMMQiqzDwclX FasCCJ0dlxELQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id BBB6A831F3; Thu, 28 Dec 2023 13:14:26 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 92F1D120FE8; Thu, 28 Dec 2023 13:14:26 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: (Stefan Monnier's message of "Thu, 28 Dec 2023 13:12:12 -0500") Message-ID: References: <835y0i92kb.fsf@gnu.org> Date: Thu, 28 Dec 2023 13:14:25 -0500 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.051 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > See patch below for my attempt to clarify. Sigh! Here it is, Stefan diff --git a/doc/lispref/control.texi b/doc/lispref/control.texi index 4107963eed5..e63660206d0 100644 --- a/doc/lispref/control.texi +++ b/doc/lispref/control.texi @@ -2311,24 +2311,100 @@ Handling Errors @code{(@var{conditions} @var{handler})} where @var{conditions} is an error condition name to be handled, or a list of condition names, and @var{handler} should be a form whose evaluation should return a function. +As with @code{condition-case}, condition names are symbols. Before running @var{body}, @code{handler-bind} evaluates all the @var{handler} forms and installs those handlers to be active during -the evaluation of @var{body}. These handlers are searched together -with those installed by @code{condition-case}. When the innermost +the evaluation of @var{body}. When an error is signaled, +Emacs searches all the active @code{condition-case} and +@code{handler-bind} forms for a handler that +specifies one or more of these condition names. When the innermost matching handler is one installed by @code{handler-bind}, the @var{handler} function is called with a single argument holding the error description. -@var{handler} is called in the dynamic context where the error -happened, without first unwinding the stack, meaning that all the -dynamic bindings are still in effect, except that all the error -handlers between the code that signaled the error and the -@code{handler-bind} are temporarily suspended. Like any normal -function, @var{handler} can exit non-locally, typically via -@code{throw}, or it can return normally. If @var{handler} returns -normally, it means the handler @emph{declined} to handle the error and -the search for an error handler is continued where it left off. +Contrary to what happens with @code{condition-case}, @var{handler} is +called in the dynamic context where the error happened, without +unbinding any variable bindings or running any cleanups of +@code{unwind-protect}, so that all those dynamic bindings are still in +effect. There is one exception: while running the @var{handler} +function, all the error handlers between the code that signaled the +error and the @code{handler-bind} are temporarily suspended, meaning +that when an error is signaled, Emacs will only search the active +@code{condition-case} and @code{handler-bind} forms that are inside +the @var{handler} function or outside of the current +@code{handler-bind}. + +Like any normal function, @var{handler} can exit non-locally, +typically via @code{throw}, or it can return normally. +If @var{handler} returns normally, it means the handler +@emph{declined} to handle the error and the search for an error +handler is continued where it left off. + +For example, if we wanted to keep a log of all the errors that occur +during the execution of a particular piece of code together with the +buffer that's current when the error is signaled, but without +otherwise affecting the behavior of that code, we can do it with: + +@example +@group +(handler-bind + ((error + (lambda (err) + (push (cons err (current-buffer)) my-log-of-errors)))) + @var{body-forms}@dots{}) +@end group +@end example + +This will log only those errors that are not caught internally to +@var{body-forms}@dots{}, in other words errors that ``escape'' from +@var{body-forms}@dots{}, and it will not prevent those errors from +being passed on to surrounding @code{condition-case} handlers (or +@code{handler-bind} handlers for that matter) since the above handler +returns normally. + +We can also use @code{handler-bind} to replace an error with another, +as in the code below which turns all errors of type @code{user-error} +that occur during the execution of @var{body-forms}@dots{} into plain +@code{error}: + +@example +@group +(handler-bind + ((user-error + (lambda (err) + (signal 'error (cdr err))))) + @var{body-forms}@dots{}) +@end group +@end example + +We can get almost the same result with @code{condition-case}: + +@example +@group +(condition-case err + (progn @var{body-forms}@dots{}) + (user-error (signal 'error (cdr err)))) +@end group +@end example + +But with the difference that when we (re)signal the new error in +@code{handler-bind} the dynamic environment from the original error is +still active, which means for example that if we were to enter the +debugger at this point, it will show us a complete backtrace including +the point where we signaled the original error: + +@example +@group +Debugger entered--Lisp error: (error "Oops") + signal(error ("Oops")) + (closure (t) (err) (signal 'error (cdr err)))((user-error "Oops")) + user-error("Oops") + @dots{} + eval((handler-bind ((user-error (lambda (err) @dots{} +@end group +@end example + @end defmac @node Error Symbols diff --git a/doc/lispref/eval.texi b/doc/lispref/eval.texi index 45c892ad5a7..c3d980e1717 100644 --- a/doc/lispref/eval.texi +++ b/doc/lispref/eval.texi @@ -848,15 +848,17 @@ Eval @end defopt @defopt lisp-eval-depth-reserve -In order to be able to debug infinite recursion errors, Entry to the -Lisp debugger increases temporarily the value of +In order to be able to debug infinite recursion errors, when invoking the +Lisp debugger, Emacs increases temporarily the value of @code{max-lisp-eval-depth}, if there is little room left, to make sure the debugger itself has room to execute. The same happens when -running the handler of a @code{handler-bind}. +running the handler of a @code{handler-bind}. @xref{Handling Errors}. The variable @code{lisp-eval-depth-reserve} bounds the extra depth that Emacs can add to @code{max-lisp-eval-depth} for those exceptional circumstances. + +The default value of this variable is 200. @end defopt diff --git a/etc/NEWS b/etc/NEWS index 014c32b4d8e..e446f05190a 100644 --- a/etc/NEWS +++ b/etc/NEWS @@ -1371,6 +1371,7 @@ It puts a limit to the amount by which Emacs can temporarily increase Provides a functionality similar to `condition-case` except it runs the handler code without unwinding the stack, such that we can record the backtrace and other dynamic state at the point of the error. +See the Info node "(elisp) Handling Errors". +++ ** New 'pop-up-frames' action alist entry for 'display-buffer'. diff --git a/lisp/subr.el b/lisp/subr.el index 600b4d27f18..57e2473c2bb 100644 --- a/lisp/subr.el +++ b/lisp/subr.el @@ -7501,13 +7501,13 @@ handler-bind "Setup error HANDLERS around execution of BODY. HANDLERS is a list of (CONDITIONS HANDLER) where CONDITIONS should be a list of condition names (symbols) or -a single condition name and HANDLER is a form whose evaluation +a single condition name, and HANDLER is a form whose evaluation returns a function. When an error is signaled during execution of BODY, if that error matches CONDITIONS, then the associated HANDLER -function is called with the error as argument. +function is called with the error object as argument. HANDLERs can either transfer the control via a non-local exit, -or return normally. If they return normally the search for an +or return normally. If a handler returns normally, the search for an error handler continues from where it left off." ;; FIXME: Completion support as in `condition-case'? (declare (indent 1) (debug ((&rest (sexp form)) body))) From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 13:22:51 2023 Received: (at 68075) by debbugs.gnu.org; 28 Dec 2023 18:22:51 +0000 Received: from localhost ([127.0.0.1]:40327 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIv1v-00020E-Fs for submit@debbugs.gnu.org; Thu, 28 Dec 2023 13:22:51 -0500 Received: from mout01.posteo.de ([185.67.36.65]:60645) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIv1t-000200-9K for 68075@debbugs.gnu.org; Thu, 28 Dec 2023 13:22:50 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout01.posteo.de (Postfix) with ESMTPS id 84EB6240027 for <68075@debbugs.gnu.org>; Thu, 28 Dec 2023 19:22:43 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1703787763; bh=U3XJl8dJxwtIOgc9sKcA+yl+zoh9+rm3BlH/nLuK+AI=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=U/hWSERdQ87t97WEemY/qnYID7h+d731+2kSEsHGKoFDLpwMif7RwTOLjTL7BO+LU 0FzuedzLQ5cluksVMZ29wAZjh6pD8EyO3DOsaNhmUcChmsPBlekCJxADYRqD9ty8Qi G93o4D+I5v4c/IrsmEVBCl5uwck4u4HO0bHwk3DHGHvgeNFfucOGl88DfjO0z/zmYZ nH00Qr0rhmChTHyMgYSeuXyb9t9ShdFxp0JT4pSLX/30csLFx2iHaZikF+xDCTouuj RogzHALiZV9ASI7r1davkcaK8QijG+f+/9hZp73XxN49OW+C8ZFAuKWDEUGCPcqclu TDqEpdoSUbxtg== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4T1H1G3nPFz6twX; Thu, 28 Dec 2023 19:22:42 +0100 (CET) From: Ihor Radchenko To: Stefan Monnier Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: References: <835y0i92kb.fsf@gnu.org> Date: Thu, 28 Dec 2023 18:25:51 +0000 Message-ID: <87bkaa6v68.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: Eli Zaretskii , 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > I'm trying to explain that when looking for a handler, we look both for > condition-case handler and handler-bind handlers and we use whichever is > "closest", i.e. more deeply nested. So just like a local > `condition-case` overrides temporarily an outer one, the same holds not > only among `handler-bind`s but also between `condition-case` and > `handler-bind` as well. Then, it would also make sense to make `condition-case' and `handler-bind' refer to each other from the docstrings. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 28 17:05:08 2023 Received: (at 68075) by debbugs.gnu.org; 28 Dec 2023 22:05:08 +0000 Received: from localhost ([127.0.0.1]:40431 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIyUy-0004mz-OO for submit@debbugs.gnu.org; Thu, 28 Dec 2023 17:05:07 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:41224) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rIyUu-0004mI-2j for 68075@debbugs.gnu.org; Thu, 28 Dec 2023 17:05:03 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 0EA3010009E; Thu, 28 Dec 2023 17:04:55 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1703801094; bh=ct7WVWB6Jdtpr4z28xEcshyNaXXyCZPYTYrMYtP5UTY=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=kV9vVpNMVcQ+E91+7eaeHsYhvrd4ar3FsoqkqlUNqkoZZjtflHBmGQdZtwmIlbhpa YtFz160uEsYcm3H8LdAsRwlA0jWOlvKw/bP9Xquld42XNugqCxbH4jqB5Pm8uSF5P8 0Q4RcBYz01mPyxM0WCmryY3J/g44d+F+B+Grq+XWmoFSz4ktR1GeI1U817pH1YyxQq 1s3UuYgtMV+gMrrBavsJYmDn+DGTR/mlzmXSBVaT356wQdiv4UKfQYTVdHcT+SPQoC hY+0Btt7pjwfgdW6Y0sb/pJ9S7PQeO9A2bw5jyeK5wE34Bh7BX5wZOiT4T880nGIg/ BhXs4v9m5ldxA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 21961100033; Thu, 28 Dec 2023 17:04:54 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id EB74D120D74; Thu, 28 Dec 2023 17:04:53 -0500 (EST) From: Stefan Monnier To: Ihor Radchenko Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <87bkaa6v68.fsf@localhost> (Ihor Radchenko's message of "Thu, 28 Dec 2023 18:25:51 +0000") Message-ID: References: <835y0i92kb.fsf@gnu.org> <87bkaa6v68.fsf@localhost> User-Agent: Gnus/5.13 (Gnus v5.13) Date: Thu, 28 Dec 2023 17:04:45 -0500 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.074 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68075 Cc: Eli Zaretskii , 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> I'm trying to explain that when looking for a handler, we look both for >> condition-case handler and handler-bind handlers and we use whichever is >> "closest", i.e. more deeply nested. So just like a local >> `condition-case` overrides temporarily an outer one, the same holds not >> only among `handler-bind`s but also between `condition-case` and >> `handler-bind` as well. > > Then, it would also make sense to make `condition-case' and > `handler-bind' refer to each other from the docstrings. BTW, `condition-case` can be implemented as a macro on top of `handler-bind` and `catch`, e.g. (condition-case ERR FORM (error HANDLER)) can become something like: (let* ((tag (cons nil nil)) (ERR (catch tag (handler-bind ((error (lambda (err) (throw tag err)))) (cons 'noerror FORM))))) (if (eq 'noerror (car ERR)) (cdr ERR) HANDLER)) :-) -- Stefan From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 30 02:50:38 2023 Received: (at 68075) by debbugs.gnu.org; 30 Dec 2023 07:50:38 +0000 Received: from localhost ([127.0.0.1]:42972 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJU7C-0006KO-2r for submit@debbugs.gnu.org; Sat, 30 Dec 2023 02:50:38 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:52276) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJU7A-0006KB-0r for 68075@debbugs.gnu.org; Sat, 30 Dec 2023 02:50:36 -0500 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 ) id 1rJU74-0004X0-Bd; Sat, 30 Dec 2023 02:50:30 -0500 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=9hqd5FX8nbB+osYOIYG3PiU+dEulROkkH8Fzz0IksG8=; b=Am/OMdfGa6VB 7TPHiVEckod1ZJ++FqT5B9lAB1HjLcR53s6uDxTfeRvad6JGbjJnroLuCa45IJoKO3BjO6aKV9OIF ls+gJraoyRvZ17IFM8WgDL4rvlcZotCpY6XcVAJksPhn2ZEk7MN+h9/jGUfTwdou9sW/kotoPhN4Y ZrRysKk6tLmVNlaKIB7CIEkXkhl90oyUE7C08QRhEJIdKSwDVJEtRmx5n3SMHTFmgq2cjxvmknv47 COFsufvDLZbTYiYo7VqeipimRdbKB1bGqgXUciVgZHsCnCItT7YQv6gEeVgSMeiigETgeFJ20LDKt ys4BL2JR23s6agjMZZHdMA==; Date: Sat, 30 Dec 2023 09:50:21 +0200 Message-Id: <83msts3z9e.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 28 Dec 2023 13:14:25 -0500) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: <835y0i92kb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 68075@debbugs.gnu.org > Date: Thu, 28 Dec 2023 13:14:25 -0500 > > +We can get almost the same result with @code{condition-case}: > + > +@example > +@group > +(condition-case err > + (progn @var{body-forms}@dots{}) > + (user-error (signal 'error (cdr err)))) > +@end group > +@end example > + > +But with the difference that when we (re)signal the new error in You want to start the above line with a lower-case "but", and you want a @noindent before it. From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 30 02:52:19 2023 Received: (at 68075) by debbugs.gnu.org; 30 Dec 2023 07:52:19 +0000 Received: from localhost ([127.0.0.1]:42977 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJU8p-0006Mz-HX for submit@debbugs.gnu.org; Sat, 30 Dec 2023 02:52:19 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:39034) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rJU8n-0006Mm-RL for 68075@debbugs.gnu.org; Sat, 30 Dec 2023 02:52:18 -0500 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 ) id 1rJU8h-0005Ej-Sx; Sat, 30 Dec 2023 02:52:11 -0500 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=Zdf5Nui7nS0/eewf1eVr5k1gLFYqTZkjbi4A2+ij7Ls=; b=APZdqF9muC+y VY5uTDHee0FKekuSMb6bSD9qd9SQUf3P5acAC2XXGTQQsVDs7rXTdb95XW0CFpRdv1ijOKACwQ1dz zZXeS27fgN78jntSv/f6KYMKPnfJ/XynZWDphTXiUmKXYs1M3SRLACwRPZVydw8Oz/LO9MB6c/bLV 3tkcT5OoTb0n/ZsOLCbmrH0usmZX9nwBpiXzzvuFIJ7nniPqt3iCQCy0SgTSynwWD/3n814orq/Ch 2ekYI3DJxdZKueGmdZA2Ku/rlyg3CQ5TK3Z9GAwgcBwQNkijQbdmVZMueFHWWLe19ohdlEQ25RCps HOJT6upXculbMfs7qU+VNA==; Date: Sat, 30 Dec 2023 09:52:03 +0200 Message-Id: <83le9c3z6k.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Thu, 28 Dec 2023 13:12:12 -0500) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: <835y0i92kb.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 68075@debbugs.gnu.org > Date: Thu, 28 Dec 2023 13:12:12 -0500 > > >> +@var{handler} is called in the dynamic context where the error > >> +happened, without first unwinding the stack, meaning that all the > >> +dynamic bindings are still in effect, > > > > Should we tell something about the effects of lexical-binding on those > > "dynamic bindings"? > > It's not related to `handler-bind` in any case, so if > we want to say something about it, we should do it elsewhere (and > I think we already do when we discuss lexical binding). Maybe I'm confused by your use of "dynamic context" and "dynamic bindings" in that passage, which somehow hinted on dynamic vs lexical binding. If this is irrelevant, maybe try to reword the text so that this potentially confusing terminology is not used? Thanks. From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 31 14:07:29 2023 Received: (at 68075) by debbugs.gnu.org; 31 Dec 2023 19:07:29 +0000 Received: from localhost ([127.0.0.1]:47029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK19l-0001mT-Fn for submit@debbugs.gnu.org; Sun, 31 Dec 2023 14:07:29 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:24186) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK19j-0001mG-8J for 68075@debbugs.gnu.org; Sun, 31 Dec 2023 14:07:27 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 385B8442B0A; Sun, 31 Dec 2023 14:07:20 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704049639; bh=mxqPYqfYViWN4qiL6Q067+ZU+2f5r2ikiMcy/OyQiVU=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=Yv+oPzolzQkYZuM1WJTUrEEjUUhd0WK+T0gSugJ8CWicw+by2iCeMos8NO7pTiKSU drmuUYE4U18w22N5QZ5NLGki5pU7Ysi2NNScnD79LXT4LGzRd7Gl1EuRotL4jTmhFk 8FviVl5Q8OR3CEHiOtfS0qcmEfpMfBoOwlGS9nW5pN+Sw+G/zLeKYhrr730+MBrmnN Yz5s1fPNL9Tgg3LGFZOorPhTMiHKZ/6PTdzd5ZRvm+3dcNN78PQw2bOrFeos2H4S38 GrHJl/yVu13Pgxh6J3JMYm377d6XNSrTl4TLV3Sy529LbzvB4NkUde8PdTES6E/idn 8Vty70dXmFXBw== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 0544E442B03; Sun, 31 Dec 2023 14:07:19 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E3D8812121B; Sun, 31 Dec 2023 14:07:18 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <83le9c3z6k.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 30 Dec 2023 09:52:03 +0200") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> Date: Sun, 31 Dec 2023 14:07:18 -0500 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 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> >> +@var{handler} is called in the dynamic context where the error >> >> +happened, without first unwinding the stack, meaning that all the >> >> +dynamic bindings are still in effect, >> > >> > Should we tell something about the effects of lexical-binding on those >> > "dynamic bindings"? >> >> It's not related to `handler-bind` in any case, so if >> we want to say something about it, we should do it elsewhere (and >> I think we already do when we discuss lexical binding). > > Maybe I'm confused by your use of "dynamic context" and "dynamic > bindings" in that passage, which somehow hinted on dynamic vs lexical > binding. Of course: "dynamic context" refers to things that include dynamically bound variable (as well as the set of active catch tags, error handlers, and unwind-protect forms), and does not include statically bound variables. `handler-bind` is different from `condition-case` in the way it interacts with that dynamic context. But for statically bound variables, well, they obey the rules of static scoping so there's nothing to influence here. > If this is irrelevant, maybe try to reword the text so that > this potentially confusing terminology is not used? Could you give an example piece of code where this "confusing terminology" makes you unsure how things would work? Stefan From debbugs-submit-bounces@debbugs.gnu.org Sun Dec 31 14:36:20 2023 Received: (at 68075) by debbugs.gnu.org; 31 Dec 2023 19:36:20 +0000 Received: from localhost ([127.0.0.1]:47054 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK1bf-0007e4-QL for submit@debbugs.gnu.org; Sun, 31 Dec 2023 14:36:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:56062) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rK1bd-0007dr-9i for 68075@debbugs.gnu.org; Sun, 31 Dec 2023 14:36:18 -0500 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 ) id 1rK1bW-00033j-MM; Sun, 31 Dec 2023 14:36:10 -0500 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=ZkJWqAFCjHnTuxSC61lqxjH1wikgT9dTSCu1E2f/o5Q=; b=kCfcpsbe3gDG J8h7WSQwc+u8ikD+KH56Tb9T1jgSzH43CoQ/aO8+TLGM/5Us1ZIIjKGcJqzGgFC16EoVXyoxgFrme jPCPIibvlcyWUapM4NTO47M8Hw++irP3QQzP9yssqHCQuU2o57orms0snOYM7dGZxoSqIC7arnmBX tXLP5n3V8Uxe5h6JZlIgDEL+poeeUIgRARPxHr927VZL1TylnbzcF8V8dbcCrPP3CQ0SCL32jzX3K YeI8YLOGqwlG2ZhsW1++YT9s1GhKtCP5udXiztRJi2hWD3r8feckAguJX1P9ncMdn63ymQreSRNZl 0iQufMf4zYNPHeAPAJ4ObQ==; Date: Sun, 31 Dec 2023 21:36:05 +0200 Message-Id: <83wmsu17x6.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Sun, 31 Dec 2023 14:07:18 -0500) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 68075@debbugs.gnu.org > Date: Sun, 31 Dec 2023 14:07:18 -0500 > > >> >> +@var{handler} is called in the dynamic context where the error > >> >> +happened, without first unwinding the stack, meaning that all the > >> >> +dynamic bindings are still in effect, > >> > > >> > Should we tell something about the effects of lexical-binding on those > >> > "dynamic bindings"? > >> > >> It's not related to `handler-bind` in any case, so if > >> we want to say something about it, we should do it elsewhere (and > >> I think we already do when we discuss lexical binding). > > > > Maybe I'm confused by your use of "dynamic context" and "dynamic > > bindings" in that passage, which somehow hinted on dynamic vs lexical > > binding. > > Of course: "dynamic context" refers to things that include dynamically > bound variable (as well as the set of active catch tags, error handlers, > and unwind-protect forms), and does not include statically bound > variables. `handler-bind` is different from `condition-case` in the way > it interacts with that dynamic context. But for statically bound > variables, well, they obey the rules of static scoping so there's > nothing to influence here. > > > If this is irrelevant, maybe try to reword the text so that > > this potentially confusing terminology is not used? > > Could you give an example piece of code where this "confusing > terminology" makes you unsure how things would work? That's the quoted part of your patch at the beginning of this message. It uses the word "dynamic" twice and "dynamic bindings" once. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 10:37:22 2024 Received: (at 68075) by debbugs.gnu.org; 1 Jan 2024 15:37:22 +0000 Received: from localhost ([127.0.0.1]:48636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKKLx-00037U-SU for submit@debbugs.gnu.org; Mon, 01 Jan 2024 10:37:22 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKKLw-00037G-13 for 68075@debbugs.gnu.org; Mon, 01 Jan 2024 10:37:20 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 9A3F244165C; Mon, 1 Jan 2024 10:37:12 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704123431; bh=XWDNxzjk9Q+II/KbMAAHyo4VdYytsW+AAV4yjz2a0wo=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=eRY7/VUL87NeVYfLGO6Xo5bd5xdvjij68DkEQ9Der70gxE2TYHuBe7UhzGiWVQeYu 6uKnhnD+LTFCNZ5KjBLNoE4kDA0gikKnSP9PFauVPGuUgQf/B1LqWaFI8WbNgGcNVD p0G1vqv6+mTX3pwkRQXoU/NAmkAggrkCwiV1GK74Sl7N1LRPmLFVqEFUtmvzpHVKuK WG2MlKf96G2yAwGgYPhrmijoxGOiRZULZW8nS96lsPnl8zdxR9eJxyWfc0k7OLAU6j C00hsFu1ao8jdUpe41pv6DCBRIZ8uMi/+EtjJXP5qKuBewDbr8t4n+HPMGGN1WBRUz ySGNIb0CpTj5w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 36B12441651; Mon, 1 Jan 2024 10:37:11 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D4134120BBF; Mon, 1 Jan 2024 10:37:10 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <83wmsu17x6.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 31 Dec 2023 21:36:05 +0200") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> Date: Mon, 01 Jan 2024 10:37:01 -0500 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 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> Could you give an example piece of code where this "confusing >> terminology" makes you unsure how things would work? > That's the quoted part of your patch at the beginning of this message. > It uses the word "dynamic" twice and "dynamic bindings" once. So, IIUC, reading that text makes you feel unsure, but you don't really know what you're unsure of? Not sure how to fix that. Should I just add a line that says that statically scoped variables are not affected? It feels kinda of odd/redundant to say that since by definition they're not "dynamic" (and also, any other behavior in this respect would be *very* weird since the handlers are clearly function *values* and thus could just as well be written/computed right *before* the `handler-bind`). More importantly I get the impression that it will still leave a lingering feeling that you're unsure about what other things could be affected (and how) or about what it means to be affected. For this reason it would help if you could try and characterize more precisely what you find confusing. Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 11:07:03 2024 Received: (at 68075) by debbugs.gnu.org; 1 Jan 2024 16:07:03 +0000 Received: from localhost ([127.0.0.1]:48652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKKog-0000jF-Vo for submit@debbugs.gnu.org; Mon, 01 Jan 2024 11:07:03 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:38796) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKKof-0000ih-GZ for 68075@debbugs.gnu.org; Mon, 01 Jan 2024 11:07:02 -0500 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 ) id 1rKKoX-0007WI-7H; Mon, 01 Jan 2024 11:06:53 -0500 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=lrIv9DsHDXUQU5ZV1B02VgBzvflryJGbv+E7SGyn54Q=; b=NJKh72jLJ69N RHht2E1/WPxldUrMNkyMB73egRFrV5HS85NRvreVsTlrAMBRxmLAkcdz7UCxxXAO5IClBVBtwPlRI t6zvtUKPk2PyTpio2BDZ2NBiaXyxaDsl9dpp1Ok385VybB8YCufSXP7bUu0PwjypaYkkq2lp4r/EE J/Gp61/eTh2efTqYJ2sIwYhEoiI2dUmc6i7wcwmX9WZ3rjaLfaHXgpt17G+XMfuRhYy0Kavgp07iD 6E/pt7rlaDCcdRuRO0S0vx2+9geUmKTm7i25ebKBfLh5W3vh8e/cKrozJ9Bijj6FUK8Xl6/fw6YYZ CoTVns8jHeBMzWjIvvB9yw==; Date: Mon, 01 Jan 2024 18:06:50 +0200 Message-Id: <83le9911id.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 01 Jan 2024 10:37:01 -0500) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 68075@debbugs.gnu.org > Date: Mon, 01 Jan 2024 10:37:01 -0500 > > >> Could you give an example piece of code where this "confusing > >> terminology" makes you unsure how things would work? > > That's the quoted part of your patch at the beginning of this message. > > It uses the word "dynamic" twice and "dynamic bindings" once. > > So, IIUC, reading that text makes you feel unsure, but you don't really > know what you're unsure of? Oh, but I do: the two references to "dynamic", including one to "dynamic binding" seem to indicate quite unequivocally that "dynamic binding" vs "lexical binding" could be involved. I wonder why it is so hard to understand this difficulty, when the words basically speak for themselves. > For this reason it would help if you could try and characterize more > precisely what you find confusing. I don't have anything else to say except point once again to your wording, which I already did several times... From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 11:55:59 2024 Received: (at 68075) by debbugs.gnu.org; 1 Jan 2024 16:55:59 +0000 Received: from localhost ([127.0.0.1]:48670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKLa3-0001NJ-2G for submit@debbugs.gnu.org; Mon, 01 Jan 2024 11:55:59 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:46791) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKLa0-0001N5-W6 for 68075@debbugs.gnu.org; Mon, 01 Jan 2024 11:55:57 -0500 Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 66643440C33; Mon, 1 Jan 2024 11:55:49 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704128143; bh=t/q1r19rGS/5hquxcW2qjnqfgfSE9efQUg1c6za9D5M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=igcu6c2TGoiQBdSWigN19lpPcDptenYClST+Kn3M3bY/OwK+Iir426ye06BO7fxl/ xlNu/+AVi/N83DDytCb9MR+vb/2pfoHqVhOcyVzXU37sH6MIlIGz4RBC7mCGbAC3Zu YubCBHkV3WQd0/oitXRMLJhpJFPTO+wfkSUrXBn/uu+WFbOY+fZuVawp15MMlXYal6 09nQHvky1C7nP4T7Q3r8cgqx7OdjxNZvzRxNaP6OHuA27JM0A2TEMWP63VEwbvdBgr AypEJnCIAyKUS8mCelVfTsh0Wp3vVK7O8dOmAm7jRWhbgHyYnJDGCD85t0wYiDb6fG PXgJLVFRcQPmg== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id DF38A440BFB; Mon, 1 Jan 2024 11:55:43 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C82E8120782; Mon, 1 Jan 2024 11:55:43 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <83le9911id.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Jan 2024 18:06:50 +0200") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> Date: Mon, 01 Jan 2024 11:55:43 -0500 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.000 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> So, IIUC, reading that text makes you feel unsure, but you don't really >> know what you're unsure of? > > Oh, but I do: the two references to "dynamic", including one to > "dynamic binding" seem to indicate quite unequivocally that "dynamic > binding" vs "lexical binding" could be involved. Yes, it is involved: statically scoped vars are not affected, while dynamically scoped vars are affected, which is why the text says "dynamic". > I wonder why it is so hard to understand this difficulty, when the > words basically speak for themselves. I guess I don't understand how "the words basically speak for themselves" leads to a difficulty. >> For this reason it would help if you could try and characterize more >> precisely what you find confusing. > I don't have anything else to say except point once again to your > wording, which I already did several times... Sadly, I still fail to grasp what kind of change to the wording could address the problem because I still don't really understand the problem. Maybe you could try to rewrite that bit in a way that you find more clear (or if there's still some part of the behavior over which you have doubts, then I'd be happily to try and explain it further). Stefan From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 12:35:35 2024 Received: (at 68075) by debbugs.gnu.org; 1 Jan 2024 17:35:35 +0000 Received: from localhost ([127.0.0.1]:48692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKMCM-0001kN-Ub for submit@debbugs.gnu.org; Mon, 01 Jan 2024 12:35:35 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51346) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKMCK-0001k4-NC for 68075@debbugs.gnu.org; Mon, 01 Jan 2024 12:35:33 -0500 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 ) id 1rKMCB-0003Tn-0M; Mon, 01 Jan 2024 12:35:23 -0500 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=3g5o5G+PcmVlt7VHHETkyzZDGxCSAx8rIER6dF2QEoQ=; b=UHsASmMdOJbf k0Erhr7VnY28/+RP9+VhHdxrT4QdsSTprwWTUf7G7MWpxiFgMCklCWu1RH2/tVs3HlD6K8a+tECQl 5/fjQY9Qr7UEXPNC+54WVIXbE9Mhzinl1XcbRdajPXiejO5RFchyGiYeJa9RsagaRsc79rUUd+AB3 zTetAq1+s29bEbpKZQfKLozDuWW8KUDiMWLYcM92haBtZFEoErY5iJWfL6BN3UqvRHwHdurkXG4fS bUm5tyOjCaqMQEfdKIEJu4AiSIM6AhSXiZ4e7V5UPRbes1SYT7RR34MOqYkcL3M6Z4iJHmggHFQV7 OyukORNYlrNf4+/2MiAFVA==; Date: Mon, 01 Jan 2024 19:35:16 +0200 Message-Id: <83h6jx0xez.fsf@gnu.org> From: Eli Zaretskii To: Stefan Monnier In-Reply-To: (message from Stefan Monnier on Mon, 01 Jan 2024 11:55:43 -0500) Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Stefan Monnier > Cc: 68075@debbugs.gnu.org > Date: Mon, 01 Jan 2024 11:55:43 -0500 > > >> So, IIUC, reading that text makes you feel unsure, but you don't really > >> know what you're unsure of? > > > > Oh, but I do: the two references to "dynamic", including one to > > "dynamic binding" seem to indicate quite unequivocally that "dynamic > > binding" vs "lexical binding" could be involved. > > Yes, it is involved: statically scoped vars are not affected, while > dynamically scoped vars are affected, which is why the text says > "dynamic". Ah, so lexical binding _is_ relevant to this, in the sense that lexically-bound variables are _not_ affected! Then please say that, maybe in parentheses or as a footnote. And please don't use "statically scoped", because we don't use this terminology anywhere in the ELisp manual. We always say "lexical scoping". > Sadly, I still fail to grasp what kind of change to the wording could > address the problem because I still don't really understand the problem. > Maybe you could try to rewrite that bit in a way that you find more > clear (or if there's still some part of the behavior over which you have > doubts, then I'd be happily to try and explain it further). I hope now it is more clear. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 01 23:56:32 2024 Received: (at 68075) by debbugs.gnu.org; 2 Jan 2024 04:56:32 +0000 Received: from localhost ([127.0.0.1]:49188 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKWpL-0001tw-OT for submit@debbugs.gnu.org; Mon, 01 Jan 2024 23:56:32 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:57211) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rKWpG-0001tf-FZ for 68075@debbugs.gnu.org; Mon, 01 Jan 2024 23:56:30 -0500 Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DC73E100068; Mon, 1 Jan 2024 23:56:18 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704171377; bh=dAjLoP5WX7fXmGZSCy4TRlUA/W3cCiHfdaKBmDXM4Xg=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=id9qIkIlRP5lboEKeMJB12IGDQx7P4RyKpXe27POxeXMpdGBjIJd/DQ893HaCOURg dDatlefFbOan826ylLddOl93b06otqBaCpY/ytiwyDq4bS3/CHCKcEyhe2LgsKFFua iPgeqwv7jHrmT9VKcUdRb8+AKgH3+FOzF8Ep9mPYMXBBVzfqaz2NYbfQCljJ+pYr9N 9rOqW9K599ex+XMW+wfWEgRTcE4TbNGXpb0oIPm+m+3LUIKG4KrdpvkDVm5YzSYhCL SN80WsNh+f64EhVi7EXFUZGb3iexZeVMzTPTL/MqFYQ2wEvjCSBElxdVgUVDug7bqy YW6dXxTZsjzHQ== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id E86B9100033; Mon, 1 Jan 2024 23:56:17 -0500 (EST) Received: from alfajor (unknown [207.96.224.130]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id D61F412004E; Mon, 1 Jan 2024 23:56:17 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: <83h6jx0xez.fsf@gnu.org> (Eli Zaretskii's message of "Mon, 01 Jan 2024 19:35:16 +0200") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> <83h6jx0xez.fsf@gnu.org> Date: Mon, 01 Jan 2024 23:56:17 -0500 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.050 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) >> >> So, IIUC, reading that text makes you feel unsure, but you don't really >> >> know what you're unsure of? >> > >> > Oh, but I do: the two references to "dynamic", including one to >> > "dynamic binding" seem to indicate quite unequivocally that "dynamic >> > binding" vs "lexical binding" could be involved. >> >> Yes, it is involved: statically scoped vars are not affected, while >> dynamically scoped vars are affected, which is why the text says >> "dynamic". > > Ah, so lexical binding _is_ relevant to this, in the sense that > lexically-bound variables are _not_ affected! Right, it's relevant to the extent that it's ... not relevant :-) > Then please say that, maybe in parentheses or as a footnote. OK. [ Tho I feel it is kind of silly, since as soon as you consider actual examples, it should become obvious that it has to be the case. ] > And please don't use "statically scoped", I use it in email messages, because I consider it to be the better term, from a technical point of view. But indeed, I don't use it in the docs, because it's too late to fix it there. >> Sadly, I still fail to grasp what kind of change to the wording could >> address the problem because I still don't really understand the problem. >> Maybe you could try to rewrite that bit in a way that you find more >> clear (or if there's still some part of the behavior over which you have >> doubts, then I'd be happily to try and explain it further). > > I hope now it is more clear. Kind of. I still don't understand how/why it helps you, but at least you say it does, which I guess is good enough. Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 18:57:55 2024 Received: (at 68075-done) by debbugs.gnu.org; 4 Jan 2024 23:57:55 +0000 Received: from localhost ([127.0.0.1]:55968 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXb1-000545-4Z for submit@debbugs.gnu.org; Thu, 04 Jan 2024 18:57:55 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:52784) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLXav-00053p-Ip for 68075-done@debbugs.gnu.org; Thu, 04 Jan 2024 18:57:53 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 38B1F84595; Thu, 4 Jan 2024 18:57:40 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704412659; bh=yLKyWSMz6vgZVDjFU20oV0Ms12uN0a/r83QSPiUpYqc=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=ErDwD27ohzFQcJuHTf0urjxpB4jtLgXNBxof5TGWPq6s4Jn4wMRUGkKIMba0vrtYi DgZmqHlhLy/fwd+34Q6k6eURWJacMtlXTnjSf85qM1Rn+i/qjV0Uk+EuGEljnJN22N ZrbZ6a0U62xatawK65pFnncbXUxwPmurZYyMcuMUL3pDufEBTHkbRvX2H1/o1NS61s eC9zIZtH7A+YUJ18+OOr/hV5Qm/rifiQThuSuPJuTr2e2TxIPcGZslN7Gig0L9Wu61 X80s06mMMdY2bu7VfLzDIFyKLCekhQRlAreFBAu0OXAsEhqvDRBPlOaHCJm8c6WD0q z/zq3GCM5Qs6w== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 3CA2A83013; Thu, 4 Jan 2024 18:57:39 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E732D120F3B; Thu, 4 Jan 2024 18:57:38 -0500 (EST) From: Stefan Monnier To: Eli Zaretskii Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: (Stefan Monnier's message of "Mon, 01 Jan 2024 23:56:17 -0500") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> <83h6jx0xez.fsf@gnu.org> Date: Thu, 04 Jan 2024 18:57:37 -0500 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.026 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075-done Cc: 68075-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Pushed to `master`, closing, Stefan From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 19:38:52 2024 Received: (at 68075) by debbugs.gnu.org; 5 Jan 2024 00:38:52 +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 ) id 1rLYEd-0005Qn-Os for submit@debbugs.gnu.org; Thu, 04 Jan 2024 19:38:52 -0500 Received: from mail-lj1-x236.google.com ([2a00:1450:4864:20::236]:48136) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYEa-0005QW-HL for 68075@debbugs.gnu.org; Thu, 04 Jan 2024 19:38:50 -0500 Received: by mail-lj1-x236.google.com with SMTP id 38308e7fff4ca-2cd0f4f306fso13114591fa.0 for <68075@debbugs.gnu.org>; Thu, 04 Jan 2024 16:38:44 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704415118; x=1705019918; 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=rgvbn+erDfhOfWVLknS9BZFtJVIKXSsXWkVIJWPvDAs=; b=nsCktufLRt8E7BDXWszvAjlXhRst8iQX9450IFDxc6UpSGKUEIf6YeCC9cSMkISnj5 ZobZRgaxmoItpzmZaVcdWFu27525QB6EYMVcuNqb8pzTRLUbDFgOyzrPNUlTLRJMy3eo yRNQP+IVhkFVUpHDHmJxcWQ7V42AdYnBeEwz0AZupWfdU2CkA0kpdjg2LwDADM6xFILd wsAK7ejreOJlvXmexoT7LNnoaoFjOCmV2MV61og5kwIN/O1CVICgGuqMkL8vGfATFQpg r91ixHtNd45a9jIPew5QIR6tIVPyUQWy5RrZ5QDafE4eNyXfRr4EC9ZvzLrOLxEEIhYb l8Aw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704415118; x=1705019918; 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=rgvbn+erDfhOfWVLknS9BZFtJVIKXSsXWkVIJWPvDAs=; b=XMQh130Waia+y82enX2UhpMqeTBGQsSSLfTNnRwtio+KhcP9HlRbfyNL26gVFp0rVH oJ9wH3oxBRuecoqlY2gjlJrrOclxWcEF01Gencqy7aKhfbcRXvPHggYYYipTO3iJyYKx n3FpCmHZ+a5TIF5FKEs8YXTxUlmIm4vvsKIigobni/VnXPgCIZdiEi8Jn/PLHdwkClsj 6HRPgPzwYX13KsMkCFpzaDuCX/jhExWa/jELfpFVKH9gAWt27fnGrCM2FiC8PrtSsGoX W1FBSv3abuGx3uJsoSmf9q27zxXKq5kgCk6P850BnKPB6pyQOMMnh3nBc+0NdWsi8Zqy ymqg== X-Gm-Message-State: AOJu0YwyWluVL3w0fG7sFi1pVRJWwNPC62ZnUJc7A7Baquhlssm5KlS4 rGCuLVXjCRbnVQ7+TaAFZiEYWPdS+OFXGJG20as= X-Google-Smtp-Source: AGHT+IHKOz8PD5vEzMrBxgheS5Or6JGnsmH6/GXYS974bUKgGKBjPk5mlXa/s8+uV6EzPGdpJ2WcL9j27VDzlnAGS7w= X-Received: by 2002:a2e:9653:0:b0:2cc:3f63:2013 with SMTP id z19-20020a2e9653000000b002cc3f632013mr691945ljh.41.1704415118389; Thu, 04 Jan 2024 16:38:38 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2024 16:38:38 -0800 From: Stefan Kangas In-Reply-To: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> <83h6jx0xez.fsf@gnu.org> MIME-Version: 1.0 Date: Thu, 4 Jan 2024 16:38:38 -0800 Message-ID: Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` To: Stefan Monnier , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: > Pushed to `master`, closing, Thanks! From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 19:51:04 2024 Received: (at 68075) by debbugs.gnu.org; 5 Jan 2024 00:51:04 +0000 Received: from localhost ([127.0.0.1]:56030 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYQO-0008QX-NZ for submit@debbugs.gnu.org; Thu, 04 Jan 2024 19:51:04 -0500 Received: from mail-ed1-x535.google.com ([2a00:1450:4864:20::535]:42253) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLYQJ-0008QF-8c for 68075@debbugs.gnu.org; Thu, 04 Jan 2024 19:50:59 -0500 Received: by mail-ed1-x535.google.com with SMTP id 4fb4d7f45d1cf-55731d88563so5732a12.1 for <68075@debbugs.gnu.org>; Thu, 04 Jan 2024 16:50:51 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1704415845; x=1705020645; 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=d5SiXyFTSYIK6gXjSbHlIwOGibGYXvFVQiaeWMx9dSY=; b=c4Vw1otw8rAgqh/uA9Ii0ZOjjW1kcWqNJMR2XypRcRFv+r1ZzetEhb/clOHSD2ftVC 45pfqlnV8ovdVb2Urt2E4me5uxCpQLSDvgBydoeuzwlejH76MlXSVDo+9Agw1uanPPBm wAOwiVUr3hlNz5B2Lg1yC+enCbyaKM8aas8Lw1KZbi8P7+FoQoK9FLM/VqJcbP79dnpm uBTKFyfNOlKplc+0rgTps3EB9CaRtLhFGUGH+kBwC2rWQdAURiHyoHBGM+nZ0wCgN4gL 9AJomgM4ja8u9PBEQZjG6/+QmADQpV6HLdCLLisB8gg6SmTK8qsJINKtffc5fi5jR429 PbIQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1704415845; x=1705020645; 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=d5SiXyFTSYIK6gXjSbHlIwOGibGYXvFVQiaeWMx9dSY=; b=X3W/6o8RCpwgKlJKSb7KI2yPfMRAlBVhPH17DPpiRpXK2SFTwxZgv2DB95DtnEBt8C EmkH8dunIGH1lbMvdV/+XnhlobxQK0NM0OQi/osp6MhWo2C1mdsVhgpYIehVntrSnt1C JIO+Y5lQWnngwnE/UaO0Chc3L0Hn/ZT3JbzmbIFo2rE0ZGXWkV2kTw4nqFirL+2ODR7z gmppH3vquUomND5T0dxAOadHP8jx/KY1j9ppBlXsZIKepoo91Vdg4/dG6WWGYoxfVpIX Ctm8tsU8lhGJ5VohyQVrt3splYZCOxKJy3q/qQb9bziEb7Wn88p8l9K3gSa5dONFeC9w vEUw== X-Gm-Message-State: AOJu0YxC66ZAFuSgP9Eq3AqDcADKg2LoeuW3btTYkksZ3snNurRE1PeH gsbdD/KLIFGBJPA6lzsBNzK4Skf0UvpReleadSP8Ea5q X-Google-Smtp-Source: AGHT+IFFGmYsKML0u5X7yBWWQjYaTce+1rKhxTM3xtYDieWOsJ3aMJU4iO0ZjstevGodI8OgFCrcaMGCrmQ7tiNZgy0= X-Received: by 2002:a50:ab4a:0:b0:553:bdae:be61 with SMTP id t10-20020a50ab4a000000b00553bdaebe61mr1342649edc.39.1704415844676; Thu, 04 Jan 2024 16:50:44 -0800 (PST) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Thu, 4 Jan 2024 16:50:44 -0800 From: Stefan Kangas In-Reply-To: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> <83h6jx0xez.fsf@gnu.org> MIME-Version: 1.0 Date: Thu, 4 Jan 2024 16:50:44 -0800 Message-ID: Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` To: Stefan Monnier , Eli Zaretskii Content-Type: text/plain; charset="UTF-8" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 68075 Cc: 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" writes: >> And please don't use "statically scoped", > > I use it in email messages, because I consider it to be the better term, > from a technical point of view. But indeed, I don't use it in the docs, > because it's too late to fix it there. I'm thumbing through my Dragon book for other reasons and they say "static scope or lexical scope". The index item for "lexical scope" says "see static scope". We already have an index entry for "dynamic scope" in the elisp manual. Would it make sense to add an index item for "static scope" too? From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 04 21:58:09 2024 Received: (at 68075) by debbugs.gnu.org; 5 Jan 2024 02:58:09 +0000 Received: from localhost ([127.0.0.1]:56093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLaPR-0007PO-0b for submit@debbugs.gnu.org; Thu, 04 Jan 2024 21:58:09 -0500 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:31985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rLaPK-0007Op-Lf for 68075@debbugs.gnu.org; Thu, 04 Jan 2024 21:58:07 -0500 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0832E8453F; Thu, 4 Jan 2024 21:57:53 -0500 (EST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1704423472; bh=aspz0D14nOIYoY8Enhf4VKf5W5TKTs5GFJ8Gziw+8dw=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=PJ/YMVtvtSYqbDxGscQsdgtpAgiUxITk3nxLKEuwwl7M20jVs5ActMtTsOqi6KGJF zjZgwHkVLtCgLk7x04phz72AFz4O7W/BTh4N3X1vXdhMTn/wwaeNLuc/Ws3UjF2AuT CbHDppdvCP/zVrSspnM+5DmRdaUdo4kjG6k3j0ISgRaDagJMENkunltb8aHrMsTgKO kZcKEwejAhfrcsZJHiD8LmuMh2coqWw7aoYPAYPpxfagI7yLSPhTT2nlX7HxhD4nmQ ZvWMDkTihh59ZNiQshn66oZJFMFY5Ur+HyHMrxcP0XpmK1n5Oj+G8XAeveTgcv/VTr 3a8vq7QXFsbdA== Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id E9F1383013; Thu, 4 Jan 2024 21:57:51 -0500 (EST) Received: from pastel (65-110-221-238.cpe.pppoe.ca [65.110.221.238]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C0B76120472; Thu, 4 Jan 2024 21:57:51 -0500 (EST) From: Stefan Monnier To: Stefan Kangas Subject: Re: bug#68075: 30.0.50; New special form `handler-bind` In-Reply-To: (Stefan Kangas's message of "Thu, 4 Jan 2024 16:50:44 -0800") Message-ID: References: <835y0i92kb.fsf@gnu.org> <83le9c3z6k.fsf@gnu.org> <83wmsu17x6.fsf@gnu.org> <83le9911id.fsf@gnu.org> <83h6jx0xez.fsf@gnu.org> Date: Thu, 04 Jan 2024 21:57:50 -0500 User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL 0.026 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 T_SCC_BODY_TEXT_LINE -0.01 - X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 68075 Cc: Eli Zaretskii , 68075@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > We already have an index entry for "dynamic scope" in the elisp manual. > Would it make sense to add an index item for "static scope" too? % grep 'static scope' **/*.texi doc/lispref/variables.texi:@cindex static scope % =F0=9F=99=82 Stefan From unknown Fri Jun 20 07:25:29 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 02 Feb 2024 12:24:16 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator