The future of Emacs, Guile, and Emacs Lisp

Posted Oct 9, 2014 13:53 UTC (Thu) by rsidd (subscriber, #2582)
Parent article: The future of Emacs, Guile, and Emacs Lisp

My feeling is speed is not an issue with GNU emacs and has not been for 15 of its 30 years of existence. And the existing extension library is a challenge for any newcomer. Where guile-emacs can win is in making it easier to write new extensions. To do that, I think it needs to be released formally in binary form -- at least via ubuntu ppa's, etc -- not by building from a git repository. That will at least get it into the hands of more people who are willing to experiment and report bugs or port extensions. Speaking of myself, I had no idea of the existence of this project until now.

The future of Emacs, Guile, and Emacs Lisp

Posted Oct 10, 2014 16:14 UTC (Fri) by lambda (subscriber, #40735) [Link] (1 responses)

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.

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.)