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

[Stefan Monnier]

>>> I'd change all these, but I can understand if that's too radical for
>>> your taste :-).
>>
>> In any case, we first have to find another solution to bug#41988.
>> I.e. a way to "undo" the effects of `edebug-make-form-wrapper`
>> or to change `edebug-make-form-wrapper` so that it matches SPECS
>> *first* and only when/if that's done do the rest (so there's no need to
>> "undo").
>
> Right.
>
> To summarize: The "culprit" is this commit:

Have you confirmed experimentally that this is the culprit for your
use case?  Do you have a recipe?

> +  (prog1 (edebug-make-form-wrapper
> +          cursor
> +          (edebug-before-offset cursor)
> +          ;; Find the last offset in the list.
> +          (let ((offsets (edebug-cursor-offsets cursor)))
> +            (while (consp offsets) (setq offsets (cdr offsets)))
> +            offsets)
> +          specs)
> +    ;; Stop backtracking here (Bug#41988).
> +    (setq edebug-gate t)))
[...]
> Do you think it would be possible to let e-m-f-wrapper just put
> something on a new "list of actions to be performed oncee the whole
> debug spec has been matched"?  I'm thinking of closures as "actions",
> here.

Maybe, but at the same time, when I read `edebug-make-form-wrapper`
I get the impression that it matches `specs` quite early on, before it
does much damage to the global state, so I think I'd need to step
through the code to better understand what was the problem that the
patch intended to fix.


        Stefan