|
|
Log in / Subscribe / Register

The future of Emacs, Guile, and Emacs Lisp

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 10, 2014 16:14 UTC (Fri) by lambda (subscriber, #40735)
In reply to: The future of Emacs, Guile, and Emacs Lisp by rsidd
Parent article: The future of Emacs, Guile, and Emacs Lisp

Speed, and concurrency, are absolutely an issue for me. When I use some of the more advanced modes which provide things like completion and M-. (go to definition) for Python, on large source files with lots of imports, it sometimes gets unbearably slow, as a lot of operations are synchronously waiting for RPC calls to the backend that is parsing your file and looking for appropriate completion candidates.

Now, I'm not much of an elisp hacker, so I don't know if it could be done better with the current backend. But if Guile will allow people to write new extensions that can more easily do operations in the background without blocking the UI, I'm all for it.


to post comments

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 12, 2014 6:14 UTC (Sun) by k8to (guest, #15413) [Link]

That seems like less of a language execution speed, and more of a design problem. (Which I think is what you are saying?) Do you know that the current design requires this type of blocking behavior? (It's typically much easier to write code that behaves this way in my experience.)


Copyright © 2026, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds