Subject: bug#68075: 30.0.50; New special form `handler-bind`

From: Eli Zaretskii <[email-masked]>
Date: Sun, 31 Dec 2023 21:36:05 +0200

> From: Stefan Monnier <[email-masked]>
> Cc: [email-masked]
> 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.