diff options
| author | Stefan Monnier | 2022-09-06 00:08:35 -0400 |
|---|---|---|
| committer | Stefan Monnier | 2022-09-06 00:08:35 -0400 |
| commit | 2a78f06ef4d303b383749be3dabd0f9a68547e5e (patch) | |
| tree | 42dcdeabc4dc6012ca2a29b40c8f85e3c3a15265 /lisp/progmodes/python.el | |
| parent | 9219e83b3c0ef53df02caf4c8ba38f482937ab50 (diff) | |
| download | emacs-2a78f06ef4d303b383749be3dabd0f9a68547e5e.tar.gz emacs-2a78f06ef4d303b383749be3dabd0f9a68547e5e.zip | |
cl-symbol-macrolet: Fix recent regression
The recent fix for bug#57397 introduced a regression, breaking
the `cl-lib-symbol-macrolet-hide` test. It turned out that the
origin of the problem was that `gv.el` uses `macroexpand-1` which
does not (can't) use `macroexpand` but `cl-symbol-macrolet` failed
to advise `macroexpand-1` the way it advised `macroexpand`.
To fix this, we change `cl-symbol-macrolet` so it advises both, and we
do that with a new `macroexpand` advice which delegates the bulk of
the work to `macroexpand-1`.
Along the way, I bumped into another bug in the interaction between
`cl-letf` and `cl-symbol-macrolet`, which I tried to fix in `cl-letf`.
I hear the war on `cl-symbol-macrolet` was a failure.
Maybe ... just say no?
* lisp/emacs-lisp/cl-macs.el (cl--sm-macroexpand-1): New function,
extracted from `cl--sm-macroexpand`.
(cl--sm-macroexpand): Rewrite completely.
(cl-symbol-macrolet): Advise both `macroexpand` and `macroexpand-1`.
(cl--letf): Don't use the "simple variable" code for symbol macros.
* test/lisp/emacs-lisp/cl-lib-tests.el (cl-lib-symbol-macrolet-hide):
Revert last change because the test was right.
* test/lisp/emacs-lisp/cl-macs-tests.el
(cl-macs-test--symbol-macrolet): Add a test case.
Diffstat (limited to 'lisp/progmodes/python.el')
0 files changed, 0 insertions, 0 deletions