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

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> To summarize: The "culprit" is this commit:
>
> Have you confirmed experimentally that this is the culprit for your
> use case?  

No, I didn't experiment.  I found the circumstancial evidence sufficient
for me.  Of course, there might be additional stuff and so on, as usual.

> Do you have a recipe?

Checkout cc0f546825e whidh should have an cl-flet where the first clause
of the &or has a def-form in it.  Then run cl-macs-tests and/or
edebug-tests.  IIRC, Stefan Kangas noticed that, which led to the
current bug.

>> +  (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.

Ok, thanks.

I'm thinking of how to proceed from here.

IMO, there's at this point enough info now that someone (tm) could fix
this, but the cost/benefit ration is sp high that I at least can't bring
me to to do it.  I can only offer to put it on my todo list, which is,
TBH, rather a to-procrastinate list.

Any other takers?

If not, I'd say let's close this or what else seems appropriate to the
maintainers.