Closed dsvensson closed 1 year ago
Interesting. Maybe cl-macrolet
has been broken in emacs master. If you want to investigate this you could look at bugs against macrolet. Otherwise a stable release should be working.
Emacs 27.1 has been released recently. So as various package managers upgrade, Dante is breaking with this problem now.
I haven't dug into things further, but happy to help if anyone has ideas of how best to proceed.
Little more context:
Debugger entered--Lisp error: (invalid-function (lcr-resume (cont &rest args) `(lcr--with-context ctx (funcall ,cont ,@args))))
signal(invalid-function ((lcr-resume (cont &rest args) `(lcr--with-context ctx (funcall ,cont ,@args)))))
flycheck-buffer()
flycheck-buffer-automatically(save)
flycheck-handle-save()
run-hooks(after-save-hook)
basic-save-buffer(nil)
save-buffer()
evil-write(nil nil nil nil nil)
funcall-interactively(evil-write nil nil nil nil nil)
call-interactively(evil-write)
evil-ex-call-command(nil #("w" 0 1 (ex-index 1)) nil)
eval((evil-ex-call-command nil #("w" 0 1 (ex-index 1)) nil))
evil-ex-execute(#("w" 0 1 (ex-index 1)))
evil-ex(nil)
funcall-interactively(evil-ex nil)
call-interactively(evil-ex nil nil)
command-execute(evil-ex)
I didn't find a bug filed about macrolet that looked like a good explanation. And upon looking into lcr
I got a bit lost and not sure where to start. Continuations and macros together are a bit challenging, not to mention my Elisp has never been that great.
I guess for now, I'm just trying to minimize the cl-macrolet call to a small example illustrating what changed from Emacs 26 to 27. Learning a little more Elisp in the process.
Hmm... I couldn't quite nail a small example that illustrates the problem... this seems to work in both Emacs 26 and 27:
(defmacro test-shajra (&rest body)
`(let ((ctx "c"))
(cl-macrolet ((lcr-resume (cont &rest args)
`(funcall ,cont ,@args ctx)))
(progn ,@body))))
(test-shajra (apply (lambda (a b) (lcr-resume 'concat a b)) '("a" "b")))
I just upgraded to emacs 27 but I am not experiencing the problem. Can you describe the exact steps that cause the issue?
I downgraded and pinned to Emacs 26... tomorrow I'll try to upgrade again, and see if I still see the problem.
After upgrading I recompiled all my packages. Perhaps this is a difference with your setup?
@jyp sorry it's taking a while... but I did just reupgrade to Emacs 27, and reproduced the same problem. However, I am running Spacemacs, so there's a possibility of interaction there. Let me switch to a vanilla Emacs installation and see if the problem persists.
If it's a problem with Spacemacs, when we can drill into that further.
Sure, no worries. Please also consider the possibility of old bytecode persisting somehow. I've been bitten myself by such an issue before (for some other package).
@jyp I cleared out my ~/.emacs.d directory and configured Dante using https://sanemacs.com (just for a baseline that didn't have a ton of stuff in it). And Dante appeared to work in Emacs 27.
So now I'm going to clear out old bytecode in my Spacemacs configuration and see if that helps. If it doesn't, then there's probably something in the bowels of Spacemacs configuration that's conflicting with Dante under Emacs 27.
So, I validated that the problem I was originally seeing is due not to Spacemacs code, but a customer layer I wrote. I don't have lot of custom code, so hopefully I can zero down on what I pulled in that caused a conflict.
In the meantime, I found another problem with an error happening in a background continuation. And that problem seems to be happening on Emacs 26, even with a minimal configuration. I'm about to look for a pre-existing issue for that.
Anyway, you could close this particular issue if you like. I've got two Dante bugs to track down. One is how I broke Dante, but only for Emacs 27 with my custom layer.
And the second is this new thing.
Ok, it's interesting that you could somehow break lcr
with custom code. And two of you did it?
I'll just leave this open. In case someone else faces the issue it will be easier to find.
Hey, I realized that I didn't get back to this. But in the meantime, I switched my Spacemacs configuration to Doom, and it seems I'm no longer hitting this problem. My focus now is on my new configuration with Doom. Just wanted to acknowledge that I may not really get to this. But I'll keep the old Spacemacs configuration around, just in case.
No worries, let's just leave it open for now until someone can reproduce the issue.
Mon Sep 21 10:40:22 BST 2020
HI,
I also had this problem after first discovering/installing dante
- just before Sept 01.
I've tested using commits since 229f0cf431c9e11643add4d33ce1928f51f4d0a3 (using emacs -Q
) and cannot reproduce.
I'll guess this may have been due to upgrading to 27.1
and not recompiling all packages.
I can confirm the problem on my side with spacemacs. However, I have also a pure minimalistic emacs config where everything works as expected.
I have a fresh spacemacs build on dfd208cf8
(emacs 27.1). I can provide more information if necessary, not sure what would be useful tho.
I have this issue. For example, it occurs when I use M-.
which is bound to xref-find-definitions
.
If you need more info, please let me know what I can do.
Can you confirm that you deleted all your .elc
files?
Okay, removing ~/.emacs.d/elpa/develop/lcr-20180902.1919/lcr.elc
has fixed the problem
Todays lcr
upgrade via MELPA (version 20210102.853) fixed the problem.
Confirmed that the latest version of lcd
(version 20210102.853) works well on emacs 28.0.50 now, thanks @vzaliva
I'm getting the following error when activating dante:
Initialized via:
Versions:
lcr-20180902.1919
dante-20200131.1211