Why can't they say that Light Table is a dead end and they discovered something else in the process (Eve)?
This is a simple truth.
For my part I think they've delivered on the spirit of their Kickstarter. They released a very usable editor that does some amazing shit. It doesn't have every feature in the Kickstarter video, but that's because reality kicked in and they had to prioritize, and found that some of the features didn't work out as well when put to other users.
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)
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.
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 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).
And use GNU Global instead of etags. Finally, keyboard boost productivity many times over the mouse.
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.
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.
In Emacs you have tooltip as well. For example, company-mode shows a completion popup like this: http://tuhdo.github.io/static/c-ide/company-clang-company-gt...
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.
No, ggtags: https://github.com/leoliu/ggtags or helm-gtags: https://github.com/syohex/emacs-helm-gtags automatically updates your tag database when you save your file. The tags produced by GNU Global is A LOT better than ctags for C/C++.
Maybe you can look at a few demo screenshots in my C/C++ guide: http://tuhdo.github.io/c-ide.html