[jamesjporter]

it's interesting how some software problems have garnered many really good solutions while others are still mired in stuff like this.

e.g. no matter what your preferred source control tool is I think we can all agree that there are some pretty good options out there these days. compare that to the insanity that prevails in packaging in every corner.

[mturmon]

Text editors are another classic example of this conundrum. Some problems seem to attract problem-solvers, and some do not.

[jjoonathan]

I don't follow. We've had TextWrangler, SubEthaEdit, TextMate, Sublime Text, and Smultron alongside rapidly improving IDEs like Coda, XCode, VS, LightTable, and a host of web-based environments like JSfiddle, Cloud9IDE, and Codepen. Text editors don't just attract attention, they attract a lot of attention, and I'm glad for it.

[mturmon]

I have used Emacs and vi since the 1980s, and view this differently. A lot of the work you refer to was largely duplicative.

Of course, I'm not talking about IDEs or web-based editors. You're right though, I do enjoy the innovation in web editors.

[jjoonathan]

First of all, drawing a line between IDEs and text editors is a surefire way to ignore the kind of innovation that is happening with regard to text-editing. If you insist on doing this then in your search for innovation you've drawn a box so narrow that you should not be surprised to find nothing in it. There are only so many pure text-editing actions with positive ROI and E&V mastered the bulk of them long ago. Even so, E&V haven't been standing still. It's true they refuse to innovate in certain directions:

1. Out-of-the-box integration with modern toolsets (0-configuration documentation, smart autocomplete, build, debug, jump-to-definition, etc)

2. Present an interface that is easily discoverable by GUI-minded folk

3. Take advantage of the opportunities afforded by non-textual displays

but each of these is done "poorly" in E&V for a good reason, as per your text editor / IDE distinction. They can't change these things without stepping on the toes of their power users (i.e. all of them) and leaving behind part of what made them great, which is why this kind of innovation is happening away from E&V. Most of the apps I listed address between 1 and 3 of the above issues. Just because the young upstart editors don't support keyboard input and customization with the fluidity of E&V doesn't mean they are purely derivative. They do something that a lot of people want done that E&V don't do, and they do it well. That's what innovation is all about.

So I ask again what it is that you would consider innovation and why the projects I listed don't count.

[mturmon]

You know what, I don't really disagree with what you are writing.

I'll repeat that we're partly talking past each other, but you are correct that the kind of (valuable! useful!) innovations you list tend to happen by an upstart and then are copied into other programs. So it is healthy to have a field of contenders rather than two dinosaurs.

You're also pitching this as some kind of argument, which I think is your mistake.

Never did I say that people shouldn't make new text editors. I remarked that some problems seem to attract developers, and some don't. I think that structural issue is more interesting than editor feature evolution.

[jjoonathan]

Yeah, I think you're right, we were talking past each other.

[mansr]

Text editors are a solved problem since Emacs was written.

[bitwalker]

If that was true then people wouldn't be trying so hard to build alternatives.

[fnordfnordfnord]

Haha... Oh. You're not joking are you?

[Shish2k]

Emacs has an infinite number of features; but the end user may be required to write a few thousand lines of configuration file to enable some of them :)

[mansr]

The power of Emacs is that the configuration file is more than just that. It is code that becomes part of the editor and can replace pretty much any part thereof if the user so desires.

[Dylan16807]

You got the joke!