Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fail to load dash when macro named as x exists #402

Open
lorniu opened this issue Jul 16, 2022 · 2 comments
Open

Fail to load dash when macro named as x exists #402

lorniu opened this issue Jul 16, 2022 · 2 comments
Labels
admin Project/release administrativia discussion enhancement Suggestion to improve or extend existing behavior

Comments

@lorniu
Copy link

lorniu commented Jul 16, 2022

I'm using the latest compiled Emacs, and if a macro named x is defined elsewhere, loading dash.el will fail.

Reading the source code, find that it is because the cl package in which the macro defsetf is located is no longer loaded, so the parameter (x) is expanded as a macro. So, an error occurred.

Hopefully this will be fixed, thanks.

image

@basil-conto
Copy link
Collaborator

"If it hurts, don't do that." ;) IMO it's unusual both to define a macro x without a prefix such as e.g. my-x, and to load uncompiled dash.el instead of byte-compiled dash.elc, especially considering how heavily Dash uses macros. So I wouldn't consider this a grave bug.

That said, I do of course agree that it would be nice to be able to load dash.el unconditionally.

One option I can think of is quoting problematic form(s) with (eval `... lexical-binding).

Another option is to finally drop support for Emacs versions 24.1 and 24.2, and start depending on Emacs 24.3.

WDYT? @magnars @Fuco1

@basil-conto basil-conto added enhancement Suggestion to improve or extend existing behavior discussion admin Project/release administrativia labels Jul 24, 2022
@lorniu
Copy link
Author

lorniu commented Jul 27, 2022

@basil-conto I have a macro called x in my custom file, but I get the error when updating packages from *packages* instead of manually loading dash.el.

I've renamed x to avoid problem, but anyone who also defined a global x macro maybe puzzled in the same scene (saw the wrong-number-of-args error when updating packages). I spend some time to deep into the source code and at last found that the root cause of the problem was the x macro, so IMO maybe some other better solution is needed. :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
admin Project/release administrativia discussion enhancement Suggestion to improve or extend existing behavior
Projects
None yet
Development

No branches or pull requests

2 participants