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

[Gerd Möllmann]

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

>>> See bug#41988 for a case where we didn't want a failure in one
>>> "definition form" to be allowed to continue matching in a second branch
>>> of an `&or` (tho this was arguably because some of the code executed
>>> along the way had side-effects that can't be undone).
>>
>> Hurrah! :-)  Yes, that's it!  Thank you so much, that made my day!
>>
>> As a fix, I'd like to propose to remove 'gate' as a debug spec entirely.
>
> It's worth a try but:
>
> - We should come up with a better fix for bug#41988/bug#41853 first.
> - We need to check the impact on current users of that gate mechanism.
>
> For the second, `grep -C9 debug **/*.el | grep '\<gate\>'`
> finds only one direct user of `gate` inside Emacs or (Non)GNU ELPA,
> i.e. `cl-macs.el`
>
>     lisp/emacs-lisp/cl-macs.el:1224:;;   '(&or (loop-var . [&or nil 
> loop-var]) [gate symbolp]))
>     lisp/emacs-lisp/cl-macs.el:2858:                                          
> (gate gv-place &optional form)])
>     lisp/emacs-lisp/cl-macs.el:2989:                  (gate ;; FIXME: Why?
>
> but there might be users elsewhere.  And more importantly it's used
> within
>
> - strings
> - `&define`
> - quoted symbols?
>
> The last one seems to be an old deprecated mechanism (a comment suggests
> it should be replaced by a string) that just has never been actively
> deprecated, so maybe we can disregard it.
> But the first two are used in a lot of places, so it might be more 
> problematic.

I'd change all these, but I can understand if that's too radical for
your taste :-).