emacs-async icon indicating copy to clipboard operation
emacs-async copied to clipboard

error in process sentinel: Invalid read syntax: "#"

Open sprig opened this issue 9 years ago • 9 comments

Hello,

When running the following:

(async-start (lambda () (set-face-font 'default "Source Code Pro for Powerline-11")) (lambda (result) (message "result: %s" result)) )

The following messages are produced:

error in process sentinel: async-when-done: Invalid read syntax: "#" error in process sentinel: Invalid read syntax: "#"

To remove the obvious, I do have the correct font installed and when run in a regular buffer, it works fine.

My emacs version:

"GNU Emacs 24.5.1 (x86_64-apple-darwin14.3.0, Carbon Version 157 AppKit 1347.57) of 2015-08-03 on sprigs-MacBook.local" Async: "20150817.2321"

sprig avatar Aug 19 '15 06:08 sprig

I think this is closely related to #17 and #22, the lambda is creating a closure that can't be read. I am also having this problem. #17 and #22 are closed, but I am wondering whether of not a solution was actually implemented.

If this is the same issue, is there any good way around it?

jordonbiondo avatar Aug 19 '15 14:08 jordonbiondo

Remember you are running code in an emacs batch (a different instance than the one you are on), what do you expect from the piece of code above ?

Of course the closure can't be read because the code you run expect buffers to work against, but it find nothing and fails.

So I see no bug here, just code that should not run async (at least with this implementation).

thierryvolpiatto avatar Aug 19 '15 15:08 thierryvolpiatto

@jordonbiondo this might be related to the previous bugs but I think it isn't (I'll looked into them previously but will do so again in a moment). The issue here is not how values are passed to the batch emacs - you can try running the following and see that it works just fine:

(async-start
(lambda () (version))
(lambda (result) (message "result: %s" result))
)

@thierryvolpiatto, As I've stated above, the closure can be read just fine. The code does fail of course - I'm not arguing that. However, if you run it in an actual batch emacs, you get the following, useful, error message:

Font not available: #<font-spec nil nil Source\ Code\ Pro\ for\ Powerline nil nil nil nil nil 11.0 nil nil nil ((:name . "Source Code Pro for Powerline-11") (user-spec . "Source Code Pro for Powerline-11"))>

And here you see the actual issue - the batch emacs fails, and outputs an error message. The async module tries to eval in some manner the result and chokes up on the '#'. Therefore, what I would expect to happen is for a message similar to the following to appear:

Error in async code. Emacs returned the following error code: <code> and the following error message: <message>

So, you are right in principle that this code should not run async. However it is sometimes (as in my case) hard to split code that should and code that shouldn't, and appropriate error messages would help identify problematic locations.

If you are interested in my particular case: I like to write papers in org-mode, and I like to see the compiled PDF as I write. If I compile it synchronously, then the process of writing gets interrupted, so I made a function that watches for file changed and thus recompiles every time I save. However, for this and for other purposes I need to load my org configuration which also depends on other parts of the config. I managed to mostly split it correctly so that I can load the just the necessary parts in batch, but those files are part of my regular config and I can sometimes put in (accidentally) changes that make it incompatible with async and thus I get the errors.

sprig avatar Aug 19 '15 16:08 sprig

sprig [email protected] writes:

Error in async code. Emacs returned the following error code: and the following error message:

You have to implement this yourself, communicating with a tmp file with the two emacs.

If you are interested in my particular case: I like to write papers in org-mode, and I like to see the compiled PDF as I write.

Probably async is not the good tool for this task, you should look at deferred and/or epc.

Thierry Get my Gnupg key: gpg --keyserver pgp.mit.edu --recv-keys 59F29997

thierryvolpiatto avatar Aug 19 '15 17:08 thierryvolpiatto

On 19 August 2015 at 12:11, Thierry Volpiatto [email protected] wrote:

sprig [email protected] writes:

Error in async code. Emacs returned the following error code: and the following error message:

You have to implement this yourself, communicating with a tmp file with the two emacs.

Already looking into this. At least there's no argument that such a thing would be good :).

If you are interested in my particular case: I like to write papers in

org-mode, and I like to see the compiled PDF as I write.

Probably async is not the good tool for this task, you should look at deferred and/or epc.

Why not? I've been happily using it for months, and it worked great until I decided to change my default font. Would you care to provide specific reasons why you think the other packages are more appropriate?

sprig avatar Aug 19 '15 17:08 sprig

P.S.

As a temporary workaround to my specific problem, I placed the problem code in a with-demoted-errors block.

sprig avatar Aug 19 '15 18:08 sprig

I'm running into this issue persistently now, even with

#+begin_src shell :async
echo foo
#+end_src

Reopening the file doesn't help, removing all other text but the code block doesn't help , running that no-hide-overlay hook workaround doesn't help, restarting Emacs doesn't help.

I don't know how to even begin debugging this. It was working 30 minutes ago 🤷‍♀️

hraban avatar Aug 12 '23 18:08 hraban

Same issue here. All source blocks that were working since ever, now return the error message:

error in process sentinel: async-when-done: Invalid read syntax: "#"
error in process sentinel: Invalid read syntax: "#"

Any ideas what can be going on?

ramos avatar Aug 29 '23 10:08 ramos

After many sweeping and unrelated updates to my Emacs version & packages it works again for me now, but I'm sad to say I have very little idea of what fixed it, or how to debug this issue. Nor how to help now that it's fixed here. Best of luck y'all!

hraban avatar Aug 30 '23 15:08 hraban