I love the concept of LightTable, basically a new Emacs with a redesigned architecture and plugin system.
I don't love that it's written inside a WebView. I don't love that the best cross-platform graphics library we have is the mess we call HTML+CSS+JS. I don't love that I have to compile Clojure to JavaScript and run it inside a WebView in order to do anything to customize it.
On the other hand, I love the simplicity of the UI of emacs. But I don't love how it's decidedly focused on text-only and its GUI is a second-class citizen. (Try scrolling per-pixel rather than per-line, and consider that tabs can only be implemented as a complete hack based on the ruler area.)
I love that Emacs Lisp compiles to bytecode and is interpreted natively. I love the simplicity of the language and its implementation and how it's integrated with Emacs. But I don't love the language itself.
If you're on a mac, the railwaycat port of emacs has pixel scrolling with the trackpad/mouse out-of-the-box. It's not as crystal smooth as you'd hope for, but it's decent.
I'm 100% with you. Feels dirty to write Clojure that becomes Javascript, I rather be writing Lua or Scheme or Python. But LT already exists, and the imaginary editor we want doesn't.
I tried pretty hard to write it, but gave up because I took the wrong approach.
I tried writing it in C and Objective-C. But this isn't cross platform for starters. Plus, C is really hard to extend cleanly using a scripting language.
I've deleted the project since, but there are probably forks floating around[1]. I'll probably give it another shot one day when I learn more.
I thought it was a fair question. You're being downvoted by overly-sensitive emacs junkies :)
I know I'm keeping an eye on lighttable (I'm an emacs users since forevs) -- it's definitely the only modern editor that seems geared to possibly being a match for emacs in the flexibility and customizability departments.
But of course, historically, emacs just incorporates whatever's interesting in other editors and continues on, more powerful than ever.
That's pretty uncharitable to LightTable which is doing a number of things differently. Inline evaluation, and great support for ClojureScript with a connected repl to name a few.
What was it a few years ago? I'm going to guess that whatever the answer is, it didn't have anywhere near the extension capability of either Emacs or LightTable.
A few years ago I would have gone with Sublime, and TextMate before that. I haven't tried extending LT, so I don't know how easy that is for a mere user. Both Emacs and Eclipse are very extensible, but only the former provides a smooth path to go from tweaking a few config variables and defining some macros, to writing serious extensions. I gather LT is mostly in ClojureScript (?), which suggests it's more like the former, but I would have to spend more time with it to say for sure. I played with it a bit, and it looks pretty, but it's not aimed at the projects I'm dealing with now.
I don't "plan" to, but I hope for it to be possible. In a couple of years, yes.
LightTable shows great promise as an editor and it's design makes it well suited to being an environment in the future.
I'm just worried that before LT gets to become what I want it to Emacs will already have what is attractive in LT. For me it's ClojureScript and much more flexible UI. If Emacs gets Guile as it's scripting language (and I think: Scheme > Clojure > Elisp) and it's UI somewhat reworked (and threads, and easy bindings to compiled code - all of which is being worked on or at least seriously considered), the decision to migrate to LT will get much harder.
Anyway, LT is the only possible choice for me other than Emacs. There is no other editor which could replace Emacs for my use cases and I don't see new ones emerging.
As a side note: I have some hope for editor embedded in Pharo. It got much better this year and continues to evolve, and being a part of Smalltalk image it is very easily hackable. Having strong editor with things like Moose/Roassal/Glamour natively integrated would be a huge win, but that's probably something I will need to do myself :)
If you are interested in helping with the Editor and improving text support in general... the first step is to help with the new text model. If you are interested, contact us. It would be nice to have that ready for Pharo4 :-)
I was under the impression that the new editor is already in Pharo 3? I don't remember all the details, but I think I at one point saw some rich editing classes while browsing packages in my image. It implemented line-numbers and other niceties. But it may have been something I installed from squeaksource. Anyway, I only recently started playing with Pharo 3, and noticed many improvements to editor, but didn't have the time to investigate so I just assumed it's already done.
I would really like to contribute somehow to Pharo development, it's absolutely fantastic piece of software. I went through tickets on official bug-tracker, but there are many of them and it's hard to tell which are important and which are being worked on. (BTW: Komitter is a very nice idea!) I didn't write to the mailing list, because I don't have (especially lately) enough time to do anything substantial; I just wanted to get some simple regression (for example) which I could fix in a couple of minutes/half an hour. The section of bug tracker with tickets like this would be a great help. Otherwise I'll certainly try to get involved more once I have a bit more free time :)
wait, let me back up for a moment wrt the original article. that screenshot in the article is not emacs. i can't give you a screenshot of emacs, because emacs doesn't even depend on a windowing system for near-maximum awesomeness. it is my go-to text editor, and i very likely will (progn several of these snippets into my .el files.
that said, we do have have windowing systems now, with some better ones on the way, not to mention touchscreens. i haven't tried out lighttable yet, but i intend to, and i greatly hope that either (1) lighttable follows in emacs footsteps of being fully scriptable (as opposed to the adopting a plugin model that's so typical of java ides) or (2) emacs devours all of that beyond-code-folding -- how best to say it? -- code-exploding (?) awesomeness that lighttable attempts to bring and that, to me, appears to map perfectly onto this new world we find ourselves in where computers are not giant boxes attached to printers anymore but are, instead, whole buildings attached to touchscreens.
doesn't matter if your program's a crocodile or wildabeast: adapt or die.
It's probably worth looking into the scope and design of LT plugins, they do (ostensibly) strive for full scriptability. Seeing some of the stuff people are doing integrating dev tools, tutorials (possibly one of the killer features in the future), etc. gives me some hope as an ardent emacs user that they may be onto something with LT.
More than windowing systems it's a different abstraction layer using what appears to me as being dom trees with very capable yet uncoupled presentation capabilities (css) instead of emacs buffer + text-properties, font-lock etc. Hoping it will unleash ideas, just like lisp did in its days, by providing a better language for logic/code interactions.
I'd like to see graphics inline, for example. Another one: in Emacs, to display inline docs, you either use the modeline, or a buffer, or a tooltip. It could be nicer... The amount of hackyness needed for adding something like a Markdown preview bothers me..
To me, LT could be Emacs with better rendering.
I really enjoyed learning Emacs, its a great design, like an open-world game. I want more apps to capture that.
Emacs supports inline graphics; you don't see the capability used all that often, but it certainly exists, and has done for quite some time.
Inline documentation doesn't seem all that desirable in the first place; from the screenshots I've seen, it looks like it would get in the way, which documentation in a separate buffer doesn't do. (I'm half tempted to implement inline documentation for Emacs Lisp mode as a proof of concept, mind you, but I really don't see the point of it.)
Previously that had been one of the differentiators between GNU Emacs and XEmacs, the latter more enthusiastically adopting GUI-, image-, and mouse-related features. I believe XEmacs got inline-image support sometime in the mid-'90s, and showed it off by including a display of the XEmacs logo in the default startup buffer.
