6 ms·

Emacs under Clojure

139 points by artagnon 14y ago

agentultra 14y ago
tromey started a project to port Emacs to pure CL (http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=709). Why not help him out instead of dividing the effort?
- astine 14y ago
  While I really hope Tromey's effort succeeds, I really think that this is probably a different effort with different goals. Porting Emacs to CL would greatly strengthen the platform Emacs is written on and would add a lot of features for free. Porting Emacs to the JVM, however, might also provide that, but would also provide simple access to the Java ecosystem, which would be a substantial boon.
  - agentultra 14y ago
    Could compile it with ABCL and get the same thing from a single code-base.
    - cheez 14y ago
      Scratching your own itch is powerful. Besides, getting up to speed on someone else's madness is not worth it most of the time.
- JoelMcCracken 14y ago
  Clojure just has more velocity than CL at this point. I'd rather see the Clojure port, personally. It would be nice, though, to see both!
- mhd 14y ago
  Didn't Erik Naggum try his hand at a CL/CLIM port years and years ago?
  - PuercoPop 14y ago
    Yeah, climacs. http://common-lisp.net/project/climacs/ http://common-lisp.net/project/climacs/ By the way. Porting the C part is one thing but what to do about all the emacs lisp packages? a compat mode?
    - agentultra 14y ago
      See http://tromey.com/blog/?p=778 http://tromey.com/blog/?p=778 where he talks about some of the difficulties. tldr; Theoretically it should just work. There are some tricky bits.
  - deleted 14y ago
    [deleted]
- malkia 14y ago
  There is an "emacs" written in pure CL - LispWorks - yes it's commercial, and not exactly the same as emacs - but very close. Some versions of LispWorks comes with the whole source of the editor, and the environment.
- zellyn 14y ago
  Anyone know his current status?
jimparkins 14y ago
Just wanted to do a bit of cheerleading for this. Do not give up. I think this will be an awesome open source project and a great project for people who are learning Clojure and want a non web project outlet to actually build plugins for. Also I am sure that people will raise LightTable in this thread as it is written in Clojure and supports plugin development - but one size does not fit all.
- SoftwareMaven 14y ago
  I completely agree. And, who knows, maybe by being built in a more modern world, it will be easier to extend in ways that solve similar problems to LightTable.
alberich 14y ago
I wonder if the guys that use emacs will really want to use another version of it running on the JVM. I get this feeling that most of them despise the JVM, and the guys who generally use JVM are eclipse/netbeans guys. Sure there will be some people that don't fit in this category. Though, it seems like the OP is trying to fix something that isn't broken. Anyways, it will be a great learning experience.
- tadfisher 14y ago
  You may be right, but those of us who currently use Emacs + SLIME for Clojure work might flock to such an editor. A subset of a subset of Emacs users, for sure, but not insignificant.
- SoftwareMaven 14y ago
  I don't think the relationship is that strong. Certainly there are people who feel that way, but there are also people who don't really care what the infrastructure is (C or Java) and just want a highly performant Emacs to work in. I don't do any JDK-related work, but I'd try it and Clojure out just for fun. If things go well, I wouldn't hesitate to switch.
- aerique 14y ago
  I'm one of the guys that uses Emacs, so this is purely anecdotal, but I'm really waiting for an Emacs with updated fundamentals. At this point I don't really care whether it is using Guile, Common Lisp or Clojure. I do like this guy's goal of making Emacs 24 the target and shedding akk the baggage of the earlier versions.
- slurgfest 14y ago
  If it is actually emacs-compatible then why does it matter what VM is underneath?
cdi 14y ago
Why not just write a similar editor, with same shortcuts, rewritten modules/modes etc, but with new architecture and paradigms?
- tadfisher 14y ago
  The existing body of Emacs Lisp packages is sufficiently large to make this a cost-prohibitive task.
- FuzzyDunlop 14y ago
  I think this is something that light table is in a better position to pull off. It's new, doesn't have to worry about compatibility, and the worst case is you have to configure it with javascript (if I recall correctly) and not a lisp. Whether or not it can, or even wants to, live up to that, is another matter entirely. But it'd be great if it does.
  - slurgfest 14y ago
    Light Table isn't going to pull off the effect of this project, because an editor which isn't compatible with emacs and isn't configured with lisp is a completely different proposition from emacs. I mean, if the Eclipse project started today, you could say similar things about it. I am sure there exist emacs users who moved to Eclipse. But...
  - dsrguru 14y ago
    You're making it sound like a chore to script in lisp. The whole point is that lisp is probably the most concise and flexible (i.e. most powerful in both the pg sense and the conventional sense) way to customize a sufficiently large environment, Clojure maybe even more so than CL.
mcav 14y ago
If this were a Kickstarter, I'd buy the top package. This is something I've wanted for a long while. Good luck!
- heretohelp 14y ago
  For anybody who codes in anything other than Clojure (although I have that too), you can partake of a 40,000 LOC elisp dotfiles repo. I have shake-n-bake modules for virtually any language or use-case you could want. https://github.com/bitemyapp/dotfiles/tree/master/.emacs.d https://github.com/bitemyapp/dotfiles/tree/master/.emacs.d If you have any requests, I can probably bake it up. Included is the awesome Ensime package for Scala and Shime (Slime) a repl for Haskell. See the link to poke around for other things. I recently restructured my dotfiles, but I once used my git repo to teach people at a Clojure meetup in SF how to get rolling with Emacs + Slime + Swank + Clojure.
  - tadfisher 14y ago
    You'll have to restructure again now that package.el is standard and better.
    - heretohelp 14y ago
      I abhor package management in my Emacs. I am also avoiding Emacs 24 for now. Yes, I'm serious.
      - tadfisher 14y ago
        It must be quite a chore to manually update all that elisp!
- hraberg 14y ago
  Thanks! I actually had a quick look at this, and Kickstarter funding is for US residents only. Indiegogo seems like an alternative (guess there are a lot of opinions on what crowd funding platform to use). Also, I'm not sure what "rewards" I could give, "listed as a contributor, in a file hidden deep in my git repo"? Anyway, more code first, then maybe revisit this!
codemac 14y ago
BT Templeton! Give us the guile-emacs[1]! The only ports that are going to actually get emacs users are ones that can eval elisp. However, good luck with this! It's like Yi.. could turn out great, or could turn out to just be a neat small project :) [1]: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002 http://www.google-melange.com/gsoc/proposal/review/google/gs...
jlarocco 14y ago
Is this a serious project meant for general use? If so, what problem is it solving? What's the advantage over regular Emacs?
- wes-exp 14y ago
  I'm curious too. I'm guessing the main draw is the ability to write extensions and enhancements in Clojure rather than Emacs Lisp?
hraberg 14y ago
Author here. Thanks for the support everyone! Seems like there is an interest in such a thing, so I'll better start hacking on this again. There are two parts to this. First, pure learning and fun - even if it goes nowhere. Second, "Extensible" is the keyword here. The goal is to find the right balance between backwards compatibility (Emacs Lisp) and forward extensibility (Clojure / JVM), so I'm not interested in writing a new text editor from scratch. I did consider Kickstarter (currently self funded), but felt I needed something running first.
- jwr 14y ago
  There is interest. Lots of people would love to see a modern-day Emacs with a modern multithreaded Lisp dialect. Problem is, Emacs is a local maximum - it is very difficult to move away from its architecture to something useful. I will be watching this project closely.
- ArtB 14y ago
  Hmm, I'm confused by "the goal is to find the right balance between backwards compatibility (Emacs Lisp) and forward extensibility (Clojure / JVM)". I assumed the idea was to write emacs in Clojure and all the modules would be in clojure so that it would entirely self-contained system with perhaps macros to make porting from emacs-lisp easier. But now it sounds like you want to write an emacs-lisp emulator in Clojure ?
  - hraberg 14y ago
    The Emacs Lisp emulator is necessary, otherwise it won't be Emacs. This part will work similar to how shen.clj[1] works. This is itself an interesting project, but as people have said, "why?" Because new extensions can then be written in Clojure (or other JVM languages) against the same core API (with shared concepts like "buffer" and "window"). Now the line of what's core and what's extension can be blurred, and while keeping backwards compatibility, one can evolve the entire architecture in Clojure, free from the constraints of the old Emacs code base. But, easier said than done! [1] https://github.com/hraberg/shen.clj https://github.com/hraberg/shen.clj

139 points by artagnon 14y ago

tromey started a project to port Emacs to pure CL (http://tromey.com/blog/?p=709 http://tromey.com/blog/?p=709). Why not help him out instead of dividing the effort?

astine 14y ago
While I really hope Tromey's effort succeeds, I really think that this is probably a different effort with different goals. Porting Emacs to CL would greatly strengthen the platform Emacs is written on and would add a lot of features for free. Porting Emacs to the JVM, however, might also provide that, but would also provide simple access to the Java ecosystem, which would be a substantial boon.
- agentultra 14y ago
  Could compile it with ABCL and get the same thing from a single code-base.
  - cheez 14y ago
    Scratching your own itch is powerful. Besides, getting up to speed on someone else's madness is not worth it most of the time.
JoelMcCracken 14y ago
Clojure just has more velocity than CL at this point. I'd rather see the Clojure port, personally. It would be nice, though, to see both!
mhd 14y ago
Didn't Erik Naggum try his hand at a CL/CLIM port years and years ago?
- PuercoPop 14y ago
  Yeah, climacs. http://common-lisp.net/project/climacs/ http://common-lisp.net/project/climacs/ By the way. Porting the C part is one thing but what to do about all the emacs lisp packages? a compat mode?
  - agentultra 14y ago
    See http://tromey.com/blog/?p=778 http://tromey.com/blog/?p=778 where he talks about some of the difficulties. tldr; Theoretically it should just work. There are some tricky bits.
- deleted 14y ago
  [deleted]
malkia 14y ago
There is an "emacs" written in pure CL - LispWorks - yes it's commercial, and not exactly the same as emacs - but very close. Some versions of LispWorks comes with the whole source of the editor, and the environment.
zellyn 14y ago
Anyone know his current status?

jimparkins 14y ago

Just wanted to do a bit of cheerleading for this. Do not give up. I think this will be an awesome open source project and a great project for people who are learning Clojure and want a non web project outlet to actually build plugins for. Also I am sure that people will raise LightTable in this thread as it is written in Clojure and supports plugin development - but one size does not fit all.

SoftwareMaven 14y ago
I completely agree. And, who knows, maybe by being built in a more modern world, it will be easier to extend in ways that solve similar problems to LightTable.

alberich 14y ago

I wonder if the guys that use emacs will really want to use another version of it running on the JVM. I get this feeling that most of them despise the JVM, and the guys who generally use JVM are eclipse/netbeans guys. Sure there will be some people that don't fit in this category. Though, it seems like the OP is trying to fix something that isn't broken. Anyways, it will be a great learning experience.

tadfisher 14y ago
You may be right, but those of us who currently use Emacs + SLIME for Clojure work might flock to such an editor. A subset of a subset of Emacs users, for sure, but not insignificant.
SoftwareMaven 14y ago
I don't think the relationship is that strong. Certainly there are people who feel that way, but there are also people who don't really care what the infrastructure is (C or Java) and just want a highly performant Emacs to work in. I don't do any JDK-related work, but I'd try it and Clojure out just for fun. If things go well, I wouldn't hesitate to switch.
aerique 14y ago
I'm one of the guys that uses Emacs, so this is purely anecdotal, but I'm really waiting for an Emacs with updated fundamentals. At this point I don't really care whether it is using Guile, Common Lisp or Clojure. I do like this guy's goal of making Emacs 24 the target and shedding akk the baggage of the earlier versions.
slurgfest 14y ago
If it is actually emacs-compatible then why does it matter what VM is underneath?

cdi 14y ago

Why not just write a similar editor, with same shortcuts, rewritten modules/modes etc, but with new architecture and paradigms?

tadfisher 14y ago
The existing body of Emacs Lisp packages is sufficiently large to make this a cost-prohibitive task.
FuzzyDunlop 14y ago
I think this is something that light table is in a better position to pull off. It's new, doesn't have to worry about compatibility, and the worst case is you have to configure it with javascript (if I recall correctly) and not a lisp. Whether or not it can, or even wants to, live up to that, is another matter entirely. But it'd be great if it does.
- slurgfest 14y ago
  Light Table isn't going to pull off the effect of this project, because an editor which isn't compatible with emacs and isn't configured with lisp is a completely different proposition from emacs. I mean, if the Eclipse project started today, you could say similar things about it. I am sure there exist emacs users who moved to Eclipse. But...
- dsrguru 14y ago
  You're making it sound like a chore to script in lisp. The whole point is that lisp is probably the most concise and flexible (i.e. most powerful in both the pg sense and the conventional sense) way to customize a sufficiently large environment, Clojure maybe even more so than CL.

mcav 14y ago

If this were a Kickstarter, I'd buy the top package. This is something I've wanted for a long while. Good luck!

heretohelp 14y ago
For anybody who codes in anything other than Clojure (although I have that too), you can partake of a 40,000 LOC elisp dotfiles repo. I have shake-n-bake modules for virtually any language or use-case you could want. https://github.com/bitemyapp/dotfiles/tree/master/.emacs.d https://github.com/bitemyapp/dotfiles/tree/master/.emacs.d If you have any requests, I can probably bake it up. Included is the awesome Ensime package for Scala and Shime (Slime) a repl for Haskell. See the link to poke around for other things. I recently restructured my dotfiles, but I once used my git repo to teach people at a Clojure meetup in SF how to get rolling with Emacs + Slime + Swank + Clojure.
- tadfisher 14y ago
  You'll have to restructure again now that package.el is standard and better.
  - heretohelp 14y ago
    I abhor package management in my Emacs. I am also avoiding Emacs 24 for now. Yes, I'm serious.
    - tadfisher 14y ago
      It must be quite a chore to manually update all that elisp!
hraberg 14y ago
Thanks! I actually had a quick look at this, and Kickstarter funding is for US residents only. Indiegogo seems like an alternative (guess there are a lot of opinions on what crowd funding platform to use). Also, I'm not sure what "rewards" I could give, "listed as a contributor, in a file hidden deep in my git repo"? Anyway, more code first, then maybe revisit this!

codemac 14y ago

BT Templeton! Give us the guile-emacs[1]! The only ports that are going to actually get emacs users are ones that can eval elisp. However, good luck with this! It's like Yi.. could turn out great, or could turn out to just be a neat small project :) [1]: http://www.google-melange.com/gsoc/proposal/review/google/gsoc2012/bpt/23002 http://www.google-melange.com/gsoc/proposal/review/google/gs...

jlarocco 14y ago

Is this a serious project meant for general use? If so, what problem is it solving? What's the advantage over regular Emacs?

wes-exp 14y ago
I'm curious too. I'm guessing the main draw is the ability to write extensions and enhancements in Clojure rather than Emacs Lisp?

hraberg 14y ago

Author here. Thanks for the support everyone! Seems like there is an interest in such a thing, so I'll better start hacking on this again. There are two parts to this. First, pure learning and fun - even if it goes nowhere. Second, "Extensible" is the keyword here. The goal is to find the right balance between backwards compatibility (Emacs Lisp) and forward extensibility (Clojure / JVM), so I'm not interested in writing a new text editor from scratch. I did consider Kickstarter (currently self funded), but felt I needed something running first.

jwr 14y ago
There is interest. Lots of people would love to see a modern-day Emacs with a modern multithreaded Lisp dialect. Problem is, Emacs is a local maximum - it is very difficult to move away from its architecture to something useful. I will be watching this project closely.
ArtB 14y ago
Hmm, I'm confused by "the goal is to find the right balance between backwards compatibility (Emacs Lisp) and forward extensibility (Clojure / JVM)". I assumed the idea was to write emacs in Clojure and all the modules would be in clojure so that it would entirely self-contained system with perhaps macros to make porting from emacs-lisp easier. But now it sounds like you want to write an emacs-lisp emulator in Clojure ?
- hraberg 14y ago
  The Emacs Lisp emulator is necessary, otherwise it won't be Emacs. This part will work similar to how shen.clj[1] works. This is itself an interesting project, but as people have said, "why?" Because new extensions can then be written in Clojure (or other JVM languages) against the same core API (with shared concepts like "buffer" and "window"). Now the line of what's core and what's extension can be blurred, and while keeping backwards compatibility, one can evolve the entire architecture in Clojure, free from the constraints of the old Emacs code base. But, easier said than done! [1] https://github.com/hraberg/shen.clj https://github.com/hraberg/shen.clj