summaryrefslogtreecommitdiff
path: root/lisp/ido.el
diff options
context:
space:
mode:
authorStefan Monnier <monnier@iro.umontreal.ca>2022-09-06 00:08:35 -0400
committerStefan Monnier <monnier@iro.umontreal.ca>2022-09-06 00:08:35 -0400
commit2a78f06ef4d303b383749be3dabd0f9a68547e5e (patch)
tree42dcdeabc4dc6012ca2a29b40c8f85e3c3a15265 /lisp/ido.el
parent9219e83b3c0ef53df02caf4c8ba38f482937ab50 (diff)
downloademacs-2a78f06ef4d303b383749be3dabd0f9a68547e5e.tar.gz
emacs-2a78f06ef4d303b383749be3dabd0f9a68547e5e.tar.bz2
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/ido.el')
0 files changed, 0 insertions, 0 deletions