bug#65516: 30.0.50; Edebug behavior of signaling errors in &or

[Gerd Möllmann]

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> This is a followup to bug#65344, which see.
>
> When Edebug matches a debug spec
>
>   (&or (... def-form)
>        (...))
>
> and the form matched against is not something def-form matches,
> an invalid-read-error is signaled, regardless of the context in which
> def-form appears.  That means the second sub-clause of the &or never
> gets a chance to match.
>
> This is not limited to def-form and not limited to &or (think
> &not, for example).
>
> In GNU Emacs 30.0.50 (build 2, aarch64-apple-darwin22.6.0, NS
>  appkit-2299.70 Version 13.5 (Build 22G74)) of 2023-08-24 built on
>  Mini.fritz.box
> Repository revision: 53c07bd04bf59f63e49af2c626714bf3fdd03ad6
> Repository branch: scratch/pkg
> Windowing system distributor 'Apple', version 10.3.2299
> System Description:  macOS 13.5

Hi Stefan,

I have a question that I hope you can help me with because you did a lot
of improvemnts there.  The question is not very important, but it's one
of those times when I can't make sense of something, and that starts
nagging me a bit :-).

My question is about edebug-no-match.  Do you perhaps have an idea what
the reason might be why it ever chooses to signal an error instead of
just throwing no-match?

I've looked through the history of edebug.el, to find out what the
use-case for signaling is, but that's difficult to follow, and I failed
to find the answer.  Probably I'm overlooking something obvious, as
usual :-).