Closed Malabarba closed 8 years ago
The issue, for reference : https://github.com/Bruce-Connor/paradox/issues/28
(sorry about the accidental close and reopen)
I have no problem with that at all, especially if it doesn't need to be a macro. Would you like to make the change?
John Wiegley notifications@github.com writes:
I have no problem with that at all, especially if it doesn't need to be a macro. Would you like to make the change?
Please be sure to not break existing code if you do that. IOW test your changes in a separate branch before commiting, in particular check if async-bytecomp.el works fine, otherwise I will get tons of bugreports now we use async as dependency for helm installation from melpa.
Thanks.
Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997
Yes, very true @thierryvolpiatto.
I'll give it a shot next time I have a moment. I can implement it as a new function, no need to change the current one and risk breaking stuff. :)
Artur Malabarba notifications@github.com writes:
I'll give it a shot next time I have a moment. I can implement it as a new function, no need to change the current one and risk breaking stuff. :)
Thanks.
Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997
As part of adding optional asynchronous operations to Paradox, I check whether async is installed and ask the user to install it.
The problem is: since async was installed after Paradox, the macro async-start doesn't get expanded on byte-compile, and later leads to an error (byte-compiled code can't call macros).
I've found a hacky solution (quoting the macro call and calling eval on it), but it would be nice to have a proper one. From what I understand of the async-start code, there's no reason for it to be a macro, it could work just as well as a function.
Would it be possible to offer it (or offer an alternative) as a function?