Emacs and Common Lisp
tromey.com
Emacs and Common Lisp
1–10 of 32 posts
Re: Emacs and Common Lisp
#2While 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 user, I suspect either they won't notice the change or the change will introduce new bugs.
Re: Emacs and Common Lisp
#3GNU 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.
Re: Emacs and Common Lisp
#4Not strictly related, but I've been thinking over a clojure+SWT emacsalike editor for a while now. It just might work.
Re: Emacs and Common Lisp
#5Not to discourage, but this will never happen, at least with mainline emacs. Of course, there's nothing stopping a fork from rewriting the lower level code as suggested, but don't ever expect it to get merged. Think a different language interpreter/operating system with a common library and applications, which is exactly what this would be.
Re: Emacs and Common Lisp
#6GNU 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.
Re: Emacs and Common Lisp
#7While 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
Also, modes like eterm always feel a bit laggy.
And all the tiny little delays add up. It does matter to me whether skipping to the end of a large file takes 200 ms or 20 ms -- only a little bit but again, it adds up.
I wonder to what extent such a rewrite could be done incrementally. For example, can the redisplay code (which is a big, complicated mess, as one commenter in the article points out) be left in C for a start and "only" the elisp-facing code be ported? If so, this sounds like a viable approach.
I also wonder whether this would help solve the problem of lack of multi-threading in current Emacs.
Re: Emacs and Common Lisp
#8GNU 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.
He did not discuss the language itself, but GNU's choices. So the "matter at hand" seems irrelevant to the correct naming of CL.
Re: Emacs and Common Lisp
#9GNU 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.
Clisp is GNU's Common Lisp implementation.
Re: Emacs and Common Lisp
#10I 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 implemented in C. What we need is a proper compiler, one that can compile Emacs Lisp to either native code, or a proper intermediate representation that can be optimized. Unladen Swallow seems like a good model.
With a proper intermediate representation, we can begin writing compilers for other languages. Then you can write your extensions in Common Lisp, or Emacs Lisp, or Scheme, or JavaScript, or Perl, or whatever you feel like writing a compiler for. This won't fragment the community, because the runtime will be the same for every language; yes, there will be syntax differences, but in the end, everyone is programming to the same API. This is different than what Vim does with its programming language support (recompile Vim to embed opaque interpreter object, pray when you choose more than one language).
The only problem is that Emacs Lisp is fine for 99.9% of use cases, and it's fast enough for 99.9% of use cases. One worry I have about "proper language support" is that people will start "engineering" Emacs extensions. (By which I mean, treating software designed for interactive use by programmers as though it's "enterprise" software. When you need to write software that must not fail, concepts like encapsulation are very important. But when you're writing software that's designed to be edited by the user while it's running, you can't write it that way. Emacs Lisp explicitly encourages this, but CL, Scheme, and JavaScript don't.)