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.
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.
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.
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.
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 ?
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.
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"?
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.
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.
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.
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.
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.
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.
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.
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.
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...
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.
