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

[Stefan Monnier]

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


        Stefan