In the comments, what important truths about GNU's nature is Tom talking about? (Where he writes "but recently I have learned, painfully, that I was only part of GNU by denying important truths about its nature.")
Emacs and Common Lisp
21–30 of 32 posts
Re: Emacs and Common Lisp
#22Not strictly related, but I've been thinking over a clojure+SWT emacsalike editor for a while now. It just might work.
Just curious: why SWT over Swing? (I've read that Java 6 included some Swing performance improvements.)
Re: Emacs and Common Lisp
#23This 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.
[Indeed](http://www.emacswiki.org/emacs/EmacsImplementations). And [this](http://en.wikipedia.org/wiki/Emacs#Other_forks_and_clones).
That said, I wonder about the possibility of taking an Emacs written in some other language and adding an Elisp interpreter to it such that it could make use of all the existing Emacs elisp out there.
Re: Emacs and Common Lisp
#24Earlier quoted context omitted.
> 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.
The problem with multi-threading in emacs isn't a lack of libraries to support threads, as CL would supply, but rather the complexities of synchronization of a large existing codebase, which porting to CL would have no effect.
Re: Emacs and Common Lisp
#25Not 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!
I'd much prefer to have all of elisp in my editor than all of Java. The existing elisp libraries are much better suited for an editing environment than Java.
Re: Emacs and Common Lisp
#26I'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.)
Not necessarily... The vast majority of emacs is written in elisp, and the amount of instructions written in C is actually rather small, It's been a while, but on the order of a few hundred too a few thousand.
Once you were to rewrite the elisp interpreter, and other calls from C into JavaScript, in theory, running emacs in you're browser isn't actually that absurd.
Re: Emacs and Common Lisp
#27Earlier quoted context omitted.
> 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.
What "unladen swallow"? That project did not have the expected improvements and was abandoned...
Re: Emacs and Common Lisp
#28GNU 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.
By using the "CLisp" when you mean "Common Lisp", you make yourself seem not knowledgeable enough to be speaking about the matter at hand.
No, he means CLisp, mr "informed"...
Re: Emacs and Common Lisp
#29Earlier quoted context omitted.
Yeah. It might be worth trying again, considering the good performance of newer language runtimes like SBCL, Node.js, and Unladen Swallow.
What "unladen swallow"? That project did not have the expected improvements and was abandoned...
Unladen Swallow might not be usable in production, but as a research project it's pretty interesting. One of its problems was supporting C-based extensions, but that's not a requirement for Emacs Lisp, and so a similar project might be more effective for Emacs than for Python. (I also like the idea of using LLVM for dynamic language runtimes, but as time goes forward this seems less likely to work out.)
Re: Emacs and Common Lisp
#30While 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 use IMAP over SSL with Gnus, and the actual talking-to-the-network is asynchronous (handled by another UNIX process). The slow part is generating the summary buffer on large groups.
(BTW, if you use IMAP with Gnus, I highly recommend using a local IMAP server instead. You can sync to your remote IMAP server with offlineimap. This speeds up Gnus enormously for me; reading my Maildir directly from Gnus is too slow to be usable, but reading it through a local IMAP server makes reading my inbox instantaneous.)