Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Emacs and Common Lisp

tromey.com

Post reply on HN
Print view View original

11–20 of 32 posts

Re: Emacs and Common Lisp

#11

Post by jff »

smountcastle wrote: post #2

While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs u…

The lack of proper multithreading has bit me many times when I try to use Emacs as an email client--start talking to the IMAP server, and your whole Emacs process takes a break. Can't edit anything, we're stuck until it either finishes or you hit C-g.

Re: Emacs and Common Lisp

#12

Post by technomancy »

julian37 wrote: post #7
smountcastle wrote: post #2

While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs u…

I use Emacs daily for 80% of my work and its performance is not an issue. Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially: * paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled * re-indenting large regions…

> I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.

Or perhaps it's the other way around: adding multithreading to Emacs Lisp would make performance no longer a problem.

Re: Emacs and Common Lisp

#13

Post by technomancy »

jrockway wrote: post #10

I guess I should really participate in emacs-devel a bit more, but I've always been in favor of allowing Emacs to support multiple languages with a common runtime. Emacs Lisp is slow, that's true, but there's no problem intrinsic to its syntax that makes it slow. Similarly, there's nothing intrinsically slow about the runtime that Emacs provides; it's a bog standard dynamically-typed language with the slow stuff impl…

> What we need is a proper compiler, one that can compile Emacs Lisp to either native code

This has actually been done (possibly badly?) and turned out to be a wash in terms of performance.

Re: Emacs and Common Lisp

#14

Post by julian37 »

technomancy wrote: post #12
julian37 wrote: post #7

Earlier quoted context omitted.

I use Emacs daily for 80% of my work and its performance is not an issue. Speak for yourself. I also use Emacs daily for 80% of my work and while performance is OK, I would definitely welcome any improvements. Areas where I notice subpar performance are especially: * paging through or searching in very large buffers (such as large log files), particularly with syntax highlighting enabled * re-indenting large regions…

> I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs. Or perhaps it's the other way around: adding multithreading to Emacs Lisp would make performance no longer a problem.

Good point. Adding multi-threading while keeping the existing elisp compiler would definitely improve responsiveness, maybe enough so to turn the issues I mentioned into non-issues. That said, the proposed approach has the potential to kill two birds with one stone: add multi-threading AND improve raw performance.

Re: Emacs and Common Lisp

#15

Post by phzbOx »

I'd rather have a Emacs on JavaScript; with a possibility to be run from the browser. (Yes I know, that'd mean rewriting everything. Not the end of the world, it'll be fun time.)

Re: Emacs and Common Lisp

#16

Post by wglb »

This has been proposed in the past.

One of the difficulties to be overcome is the huge base of existing elisp code. This code base is part of the attraction of emacs.

Re: Emacs and Common Lisp

#17

Post by bitdiddle »

drcube wrote: post #3

GNU already chose Scheme as the language of choice for Guile, which is (intended to be) to GNU as a whole what elisp is for Emacs. So I could see emacs eventually being ported to Scheme. But not CLisp.

If I recall that's already in the works

Re: Emacs and Common Lisp

#18

Post by drewr »

jff wrote: post #11
smountcastle wrote: post #2

While this sounds like an interesting and ambitious project, I don't think it will ever get off the ground. I use Emacs daily for 80% of my work and its performance is not an issue. The author seems a bit too optimistic that a GCC plugin can automate the majority of the port to CL -- it may provide a nice start but finishing the port will me a considerable amount of tedious work and from the perspective of an Emacs u…

The lack of proper multithreading has bit me many times when I try to use Emacs as an email client--start talking to the IMAP server, and your whole Emacs process takes a break. Can't edit anything, we're stuck until it either finishes or you hit C-g.

I run a dedicate instance for Gnus for exactly that reason. Has the added benefit of keeping me from being distracted by a simple (Emacs) window change when I'm focused in my other instances.

Re: Emacs and Common Lisp

#19

Post by jrockway »

technomancy wrote: post #13
jrockway wrote: post #10

I guess I should really participate in emacs-devel a bit more, but I've always been in favor of allowing Emacs to support multiple languages with a common runtime. Emacs Lisp is slow, that's true, but there's no problem intrinsic to its syntax that makes it slow. Similarly, there's nothing intrinsically slow about the runtime that Emacs provides; it's a bog standard dynamically-typed language with the slow stuff impl…

> What we need is a proper compiler, one that can compile Emacs Lisp to either native code This has actually been done (possibly badly?) and turned out to be a wash in terms of performance.

Yeah. It might be worth trying again, considering the good performance of newer language runtimes like SBCL, Node.js, and Unladen Swallow.

Re: Emacs and Common Lisp

#20

Post by Bootvis »

regularfry wrote: post #4

Not strictly related, but I've been thinking over a clojure+SWT emacsalike editor for a while now. It just might work.

It's a Heruclean effort but would be great. Imagine the possibilities of having all of Java available in your editor!
Post reply on HN