It once again brings attention to the most important "bus factor" [0]
I understand the idea that "development may have stopped", but there are not any glaring bugs, sublime text 3 is super fast, and there is a huge community building sublime plugins.
The editor was built in such a way where it allows the entire community to keep moving it forward even if the original developer has moved onto other things, and I happen to think that is great.
I'm not sure that editors like vi and emacs receive regular updates. It seems that emacs releases can have up to 2 years between versions, and I can't find the last time that vi was updated. Those do have the advantage of being open sourced, but unless there are glaring holes in Sublime then I don't see this as a big problem.
Besides all that it DOES look as though there are plans for the future of Sublime as someone mentioned in a forum post on here. If it is true that development has been focused on improving the payment system for purchasing Sublime then I am all for that.
http://en.wikipedia.org/wiki/GNU_Emacs#Release_history
http://en.wikipedia.org/wiki/Vim_%28text_editor%29#Release_h...
In between major releases they have tons and tons of bug fixes (Vim probably has hundreds per release).
Editors can suffer a lot from code rot since they have to integrate with a lot of things. An Open Source version could be quite interesting from Sublime's community point of view. I don't know about the developer's income while this happens, though.
Honestly though. Emacs was first released almost half a century ago. Its core is fairly feature-complete. It doesn't need intense development and constant releases.
Besides, at least for Emacs, one of the main driving principles is for it to have a good & stable core, and have all the bells and whistles delivered via extensions and packages. And those extensions gets updated continuously. Often from git commit to git commit, depending on author.
When you have decades worth of customizations and ecosystem-code to consider, keeping the core stable is the only strategy you can possibly choose.
Your comparison isn't apples to oranges, it's 40 years old whisky to diet coke.
Edit: Half a century, not decade. Thanks dragonwriter.
Closer to half a century, which I guess reinforces your point.
I regularly have 15+ projects open, all of which I work on regularly, and I probably have 30+ projects that I work on regularly that I don't bother to keep open, simply because the window menu grows too long. I use the next/previous window commands to cycle, but sometimes I have so many projects open I have to use the window menu, which coincidentally seems to be randomly ordered, so it takes a long time, relatively speaking, to scan.
There is no way to quickly switch between per-window projects. I tried to write a plugin for this (giving you a cmd-P-style project switcher), but it turns out the API doesn't support switching windows; you can find a window, but focusing it doesn't do anything if it's not the current window (something I consider a bug, but the developer never responded to my bug report). You can't create new windows, either.
Some other things:
* Sublime is fast, but it could easily be faster. Large files are quite slow to open, even in ST3.
* The sidebar needs work. SidebarEnhancements is great, but not enough. There's no Git integration, for one. No mode flags. Renaming and moving files is cumbersome. No multiple selection.
* The global file search functionality is pretty bad. It opens up a new buffer, but it appends to the current one if there is one. You can only double-click on the match, not on the context lines. My wish list item is for the search results to be a live view into the matching files, so that I can actually edit within the results buffer.
* Package Control needs to be moved into the editor and become a first-class citizen. It's weird that it has to be added manually.
* Syntax highlighting per file-pattern, not extension. For example, .js.erb is an ERB template containing JavaScript, but there is no way to tell Sublime this; syntaxes can only be associated with the last extension.
* Lots of tiny things. For example, Sublime doesn't have a built-in way to filter a selection through a Unix command (eg., "sort"). Turns out process management in a plugin is awkward.
I could probably think of a bunch more.
> My wish list item is for the search results to be a live view into the matching files, so that I can actually edit within the results buffer.
There's a plugin[1] for that btw, but I'm not certain it's completely safe for use. Last time I checked you could only modify the search results once.
>Syntax highlighting per file-pattern, not extension.
Luckily, there's a plugin[2] for that too.
>Turns out process management in a plugin is awkward.
I've never had a problem with that. Are you new to Python?
[1]: https://sublime.wbond.net/packages/FindResultsApplyChanges [2]: https://sublime.wbond.net/packages/ApplySyntax
I'm not at all new to Python. Forking processes is simple enough, the problem is about how Sublime manages the plugin thread; you have to jump through hoops with sublime.set_timeout() etc. At the time, I was having huge issues waiting for a process and then afterwards interacting with the editor; it seemed buggy. I'm sure it's possible given enough trial and error.
Apparently some people, still believe the theory that all you need to know about a product is on the price tag, which is absolutely false (e.g. emacs/vim have no price but are exceptional programmig editors, hardly matched by payware solutions).
Anyway, it's good to have choices.
IIRC -- and I was never a TM user but was following it from the outside -- search for a TM replacement started before the open-sourcing; once TM became popular, people started looking for a cross-platform equivalent (because even lots of people who are primarily OSX users don't do all their editing there) and as the perceptions was that development was stalling, an even more people were searching for alternatives. The open-sourcing was sometime after that.
I don't think ST has been adopted because it is payware (that is, I don't think a significant force in its adoption is a preference for paid over free software), I think its been widely adopted because its features well match what a lot of people are looking for in an editor, and they are willing to pay for it.