GNU bug report logs -
#65516
30.0.50; Edebug behavior of signaling errors in &or
Previous Next
Full log
View this message in rfc822 format
Stefan Monnier <monnier <at> 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 :-).
This bug report was last modified 1 year and 350 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.