While freehunter is right, I think it's more that LightTable is too unfinished to be considered dead.
LT fills multiple spaces in the area of IDEs:
- An extremely-programmable IDE (there's no other one like it)
- A lightweight generic IDE (there's REALLY no other one like it). I almost wouldn't call it an IDE but it's more than a text editor... it's right in the middle of the two and it's great to have something fill that gap, especially for languages that don't always need full-blown IDE support (like python and clojure)
Heh okay, emacs is extremely programmable. I don't really consider it an IDE but that's fair.
It'd take a long time to explain the differences but emacs is far from lightweight, it's a beast. LT is very barebones. And LT is written in HTML/CSS/CLJS which makes it stylable and programmable as such, a real advantage over emacs.
Emacs is an IDE, first and foremost, to Emacs Lisp itself. Other Lisps are close. It's an excellent editors for other languages, and a good enough IDE for some languages. See my C/C++ guide in Emacs: http://tuhdo.github.io/c-ide.html.
Fyi, people wrote parsers, chat and email clients in Emacs that LT is still dreaming.
I use Emacs every day, and I think Emacs makes a terrible IDE or anything resembling an IDE. It's too slow, the GUI is too primitive, there's a whole host of other problems. I'll dump Emacs the instant something that fixes those issues comes around.
A few things are either slow, highly annoying, broken, or all three:
etags -- it's just an nightmare, full stop. It only gets you where you want to go half the time at most. And then because the GUI is so primitive you can't do basic things like click on a symbol and have it jump you to the definition, you're stuck using the keyboard interface designed for work in a terminal.
An etags that actually worked properly is one of the most basic things that could improve my productivity monumentally.
CEDET -- last used about 5 years ago, gave up because on larger files/projects it would just hang my editor for a few seconds as it processed.
Variable/symbol completion -- see etags.
I'm not doing a very good job communicating my dislikes / pain points because I'm not very good at communicating. Please do not respond with a "but these aren't problems because..." because they are problems for me, I just do a poor job of communicating.
I think you communicated your pain points well, because they are my pain points as well.
I gave up on emacs for Java development for the reasons you cited, but I still use it for REPL style development (Jython, Ruby Motion, XQuery, as a few current examples).
You are pretty out of date then. See my C/C++ guide (with demos): http://tuhdo.github.io/c-ide.html. It works fine on navigation projects like Linux kernel, it should work for you likely. With Projectile, I can jump any file instantly, even in Linux kernel with more than 46k files, and I've never seen this in an IDE.
And use GNU Global instead of etags. Finally, keyboard boost productivity many times over the mouse.
Ah yes, the good old "mouse? you're doing it wrong!" bit of elitism. Some people find keyboard navigation through a second buffer that pops up on the bottom to be not-good. I'm one of those people. I hate it when completion buffers, or anything related to a second buffer, pops up in my frame.
Google Chrome, or any modern browser for that matter, has a much better way of doing things. Imagine for a moment that I was browsing and editing code in Google Chrome instead. A symbol would be a link, and when I ctrl+clicked on it, it would open in a new frame. That would be an interface I could get behind.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
Ah yes, the good old "mouse? you're doing it wrong!" bit of elitism. Some people find keyboard navigation through a second buffer that pops up on the bottom to be not-good. I'm one of those people. I hate it when completion buffers, or anything related to a second buffer, pops up in my frame.
There's nothing elite about the keyboard. It's just the keyboard enable higher productivity when it comes to write code.
For completion, it ought to work like the IDE I used back when I was writing Scala. A little tooltip would pop up with completions. You could scroll through them with the mouse or keyboard, and click or ENTER the one you want and it would paste in. Or you could ignore it completely and continue typing. This sort of UI is so much better than popping up a new buffer in the frame. But in Emacs UI, everything is a buffer and there are only three places they can (or usually do) go: in a new frame, in a new window, or in the minibuffer. Only that last one is usable.
Completion using a window buffer is still vastly superior because it can handle large collections. For example, here is how I filter completion candidates with Helm: http://tuhdo.github.io/static/c-ide/semantic-boost-demo.gif. Helm works even if you have 99999 candidates (not joking) to filter out. Here is how I quickly filter to a file and enter the file in Linux kernel source tree: http://tuhdo.github.io/static/helm_projectile.gif , very quick and simple; in contrast, the file search dialog box in typical IDEs is very complex with many checkboxes and text fields. How do you cope with completion popup with contains thousands of candidates in it?
GNU global is not a solution. It produces marginally better output than etags, but still requires you to actually run it whenever you make changes to the codebase. Or at least it did back when I tried it as an etags replacement.
i've not used lighttable, but as far as filling in the space between editor and ide goes, geany does a decent job. it doesn't have a ton of features, and the plugin mechanism is some combination of C and lua (which raises the entry barrier a bit), but it's definitely targeting that exact space.
LT fills multiple spaces in the area of IDEs:
- An extremely-programmable IDE (there's no other one like it)
- A lightweight generic IDE (there's REALLY no other one like it). I almost wouldn't call it an IDE but it's more than a text editor... it's right in the middle of the two and it's great to have something fill that gap, especially for languages that don't always need full-blown IDE support (like python and clojure)