But in terms of management I think they're making two mistakes:

1) I bet almost everyone that uses Sublime Text for production work are using the "Beta" version (3) and not the release version (2). However, version 3 is suppose to be a paid upgrade from version 2. How long can you leave money on the table like this and still have a business, especially when the "beta" status probably doesn't have much meaning with your customer base? Maybe these guys have day jobs and this is just funny money anyway...

2) By remaining in beta so long and now that many people are using it... when they do pull the release trigger on version 3, that will be a very sudden expense for people that maybe have grown to depend on it without having paid for the upgrade. While everyone on version 3 should know that the day will come when that's a new license to pay for, if it rolls out as a standard update and doesn't obviously leave room to stay on the last beta version while people digest the upgrade fee... you might see a lot of people upgrade to the alternative editors instead. (OK, OK... that's a potential management mistake, not a concrete one as yet...)

2) In terms of the expense, the only people who will be required to pay an upgrade fee are users who purchased a license before the Sublime Text 3 beta was announced. So effectively users who have been using ST2 (or ST3) for more than four years will be paying. Everyone who has purchased since the ST3 beta announcement have an ST3 license already (http://www.sublimetext.com/blog/articles/upgrades).

Let me compare this to how I decide if something should be released: Is it stable (ie: it doesnt crash frequently)? Did I add some features so I can tell users its better than the last version? If you answered yes to those questions, then fix any major bugs and ship the thing as stable.

You would have been on 3.0 stable a long time ago.

I also would package each of these fairly minor releases as 3.x.. so this release would probably be 3.25 or something.

Why? You mark it as stable so new users (who aren't aware of your process) know they can use this (and you can close the sale). You want people to feel like the project is active, and they're getting a good deal for the license.. which feels like a better deal to you? - I bought ST2 and will get ST3 - I bought ST 3.0, and received over 30 releases from 3.0 to 3.30.

Yes, well over 90% of Package Control users are running Sublime Text 3.

This is a warning sign. You were so conservative with marking it stable, that the users have made the decision for you. The beta is now your product, and if you break it, that will be your reputation. You no longer have a real beta.

[beta][stable release][active development][extended support][eol]

ST seems to call the entire period through active development "beta".. and then when they've finished developing the entire thing and hit what would normally be the extended support period (bug fixes only), they call it stable.

It's certainly costing them money. And reducing the value of licenses (since its "stable" for a shorter period of time)

If I were them, I would wait a couple of weeks (so that they get the entire benefit from their announcement today of this new build), and then re-release their software as stable -- even if no changes were made to it during that period.

This thing has been in beta since 2013. It's been tested enough. It's ready.

(And to ST: if you want free advice on your release process, you're more than welcome to email me. Or at least talk/consult with someone with product management experience.. your software is great, but this release process needs to be fixed.)

As a longtime customer, I wish there was more communication about the state of things, and plans for features, things like that.

Basically, more communication, and less radio silence.

I'll leave you with this... My wife worked in Hollywood for a long time and we knew some wanna-be script writers... some of them wouldn't ever try to get their scripts sold or read because... for years on end... the scripts "weren't ready yet"... those guys usually just ended up doing other work and never selling a script since they couldn't live without cash flow. Don't be those guys :-)

Your standards of quality are admirable! ST3 is the most immaculate text editor I've ever used (never used ST2). If ST3 is beta, then in comparison Atom or even Vim are still in alpha.

[1] https://www.sublimetext.com/sales_faq

So they dodged my point two. I hope they don't amplify point 1 with that move.

[Update] Actually, this is not fully correct in regard to my point. I re-read your link and this is the key bits.

"Until such time, upgrading is not required, as Sublime Text 3 will accept Sublime Text 2 license keys during the beta period. [...] For customers who purchased in the 90 days prior to the announcement of Sublime Text 3 [Jan 2013], we are reducing the cost of upgrading from $15 down to $11. Customers who purchased Sublime Text 2 before this time period are still subject to a $30 upgrade fee when 3.0 is released."

So version 2 subscribers are not automatically grandfathered into version 3; there is a class of version 2 users that are, but not all. Apparently there is a time at which they considered licensing to be version 3. http://www.sublimetext.com/blog/articles/upgrades.

So for example, I bought a version 2 license in 2012, have been using version 3 since 2013... an automatic update to a full release version would force the update issue.

[1] https://web.archive.org/web/20130518184355/http://www.sublim...

Today's customers are paying for continued development, for future releases. If a product is dead, there's near zero chance I'd pay for it, or use it (willingly).

If this dev is happy, I'm happy. When I was in the game, I was thrilled to have steady income, enough to stay solo and continue to do what I loved.

(I bought a personal license and make each of my employers buy me a work license. I love SublimeText and am happy to pay.)

I understand people who need/want it because it's snappier and handles large files great. I am however not really one of those people. But I am happy to see development on it.

Plus, the Latexing plugin has mendeley support and really, that's _so good_ that I am willing to pay for it and stay and be happy. You have not known latex joy until you have created a bibfile using intellisense-like reference searching and nothing else..

[1] https://github.com/James-Yu/LaTeX-Workshop

Nowadays I'm using Neovim very comfortably.

https://github.com/gumieri/dotfiles

If ST3 had the same features (basically, more support for friendlier plugin integration) it would totally devastate those, apart from in price (which should be irrelevant for professional developers anyway).

But even as it is now, it's way handier (due to the snappiness) for everyday coding than VS Code (Atom is so slow it doesn't even qualify).

How big is your project that you find atom slow? I have gone back and forth between atom and sublime 10 times in the last 10 minutes and I have not found a single reason why anyone would notice a lag in a project of just a shade over 10,000 files. The difference in speed is completely imperceptible.

Not saying I love atom more than any other editor (I typically use terminal vim) but in my experience over the last week, any complaints about atom's sluggishness seems either outdated or wrong to the point of absurdity.

All that said, Sublime is not my daily driver. I use JetBrains products for that. I mostly use it to jot down notes that will eventually be transferred somewhere more permanent, temp access tokens for APIs, small snippets, JSON files, Mardown files, etc. If my main use with ST3 wasn't frequently opening and closing it, relying on its great performance when opened with my actual IDE(s), and abusing its second-to-none ability to keep files saved without actually saving them to disk, I may feel differently.

Different guy here, but I don't thing project size has much to do with it. For me it's UI for the most part. Most of the time I can see, how the moment text goes from "simple text" to the "highlighed text" (and all of the formatting too). I simply can't stand this. Same happens when searching a large file (I do work with logs pretty often). But this problem is solved in Atom for the most part - you still can't open files larger than 10Mb...

And as a separate issue - the latest update made it impossible to update Packages for some reason. All I'm getting is "undefined" error.

[1]: https://github.com/atom/apm/issues/620

Thank you, random citizen.

It's perceptible to me, even in VSC (which runs circles around Atom).

And perhaps Visual Studio Code, although I would consider that an IDE (not a big fan of IDE's)

For the most part, the Electron UIs use a ton more RAM and are much laggier. They do not tend to handle large files well. However, in exchange for that, they offer rich features. Plugins are way better - since obviously they have HTML/CSS at their disposal.

Also, VS Code's community is very active - same for Atom - and it leads to quite high quality plugins. The plugin for Go, for example, is quite great. I've been hoping for first-class Go support in Sublime just so I'd have a direct comparison, but in comparison to the VS Code plugins for Go, Sublime feels outright clunky and hard to configure.

I'd say give it a shot. If you can get past the fact that it's undoutably slower, and some of the semantics are different, it's really nice having full code intelligence and rich plugins.

Still glad that there's an alternative available to VSCode also. :)

Sublime Text:

* Faster, performs better which is especially visible on budget computers or when handling larger files. Sublime is really, really good in handling large files while Atom or VS Code really stinks when it comes to that.

* A lot of plugins because it was "first" of these new, great text editors. Many plugins varies in quality but they exist.

* Very easy to configure and make the editor a perfect fit for you. Atom and VS Code has the same configurability, but they simply copied Sublime on this part.

Atom:

* A LOT of plugins and extensions. Seriously. It feels like there is an extension for everything already.

* Snappy enough, easy to search and find stuff in your code.

* Great, simply great UI and font rendering. With some theming this editor is by far the most beautiful one.

VS Code:

* Snappier than Atom, but with deeper features in the box. Got stuff like git tools, intellisense and other goodies that is just missing in Atom.

* Insane support for Typescript (and perhaps other languages as well). There is simply no other editor you want to develop Typescript in. Also good for compiling .NET Core (these are the ones I've tried).

* A lot of great quality extensions from Microsoft and others. While Atom might have more extensions, I find those for VS Code often to be more quality ones and I have yet to uninstall a extension because it doesn't work or is buggy.

Personally, I prefer VS Code because it feels more snappy than Atom, has intellisense and good support for compilers like .NET and Typescript.

Sublime is better when working with structureless files (plain text logs etc.).

[0]: http://langserver.org/

Atom, while also not an IDE, is way heavier, to the point of being slower than actual full fledged IDEs.

edit: Whoops, didn't see a couple comments already saying this. My bad.. consider it an echo then.

Before we had:

    1. Delphi
    2. Visual Studio
    3. Eclipse

    1. Sublime Text
    2. Visual Studio Code
    3. Atom

[0] https://github.com/Microsoft/vscode/issues/55

As usual, drop by the forum to provide feedback: https://forum.sublimetext.com/t/dev-build-3132/28529

I've been previously using someone's script to install Sublime on Fedora: https://gist.github.com/simonewebdesign/8507139

An official DNF repo is much appreciated.

2. See definition of a function - copy name of function

3. Open new folder -> say 2 folders above the current file

4. Right click -> Find in Folder, paste name of function, enter

5. Get an overview with:

- a list of files where the function name is found

- for each line the surrounding code is also shown

- double clicking on a filename opens said file in a new tab

I have yet to find any vim/emacs tool that can do this so easily and effortlessly. Even with Emacs Projectile, you have to define a "project"? And then grep in that (but the user interface is just subpar).

Maybe I'm missing something, but for me, this is effectively stopping me using Vim/Emacs most of the time. I use Vim for editing individual files, but anything more than that, it is either IDEA (ok, I do Java dev a lot, so that's a must), or any Commander clone (which has a Find functionality).

You want cscope integration. Nothing compares to this in terms of ease of navigation - and I say that as a dedicated ST3 user. How to integrate cscope with vim:

    http://cscope.sourceforge.net/cscope_vim_tutorial.html

There are a few components: 1) Some fancy keybindings, 2) A plugin, and 3) an optional wrapper script for launching commands inside a git project.

First, keybindings. You know about '#' and '*' in vim that search for the next occurrence of token under your carat? I have an additional binding that does the same, but doesnt move the carat. I bind it to <CR> (Enter), but you could bind it to whatever. If you bind it to <CR>, it will interfere with the minibuffer, which requires some shenanigans to work around (see the vimrc)

  nnoremap <silent><CR> :let @/='\<<C-R>=expand("<cword>")<CR>\>'<CR>:set hls<CR>

I use mhinz/vim-grepper to execute searches, with my vimrc I can move the carat to the word I am interested in, press "enter", then type :Gr<TAB><ENTER> which will put me into grepper. Then I can press ^R/ (that is ctrl-r then /) which pastes the content of the '/' register. Grepper will then launch the selected search tool (ag, grep, git grep) and create a mini buffer of matches that you can click on, or highlight and press enter. Here is my vimrc if you want to give it a go. BE WARNED the first line of the vimrc calls git clone, if this is bad on your setup for some reason, dont use my vimrc.

https://gist.github.com/SeamusConnor/d7ebb747c91845055e069f0...

The last piece is executing the search from the correct directory, to do that, I use two methods. First, vim has a built in way to change its working directory (:chdir), so you could do a :chdir ../../. Second, if you are using git it is nice to run commands at the top level of the git directory sometimes. For that I have a script that translates commands from the CWD to the git top level. Some things you can do with it:

Rebuild cmake style project:

  g make -C build && g ./build/my_program # you can execute this from anywhere inside the repo

  cd src/my/nested/folder/
  g vim my_source_code.cpp  # open vim at git top level directory, and translates the file to src/my/nested/folder/my_source_code.cpp

Anyway, hope that helps you or someone else.

To be a bit more specific: I need to see the structure of what I'm searching in, so at minimum, that means neotree/nerdtree. I don't have photographic memory, or alphabetic memory, I always forget the names of folders, files, everything. I just couldn't care less. "../.." means nothing to me. What is that directory? Show me, and I will point to what I want.

Also, I don't want to search in a project. I want to search in a project OR in multiple projects OR in a subdirectory within a project, ad hoc. OR just select some files and search in them.

And in my opinion, for this specific use-case there is nothing wrong with using the mouse. When I'm searching for something in the way I described above I am usually browsing the code, reading it, trying to understand what is going on. This is different to when I'm actually coding something, then vi/emacs suddenly gets much more attractive, depending on the language used :)

Emacs on the other hand provide very nice integration with various REPLs and functional languages have best tooling in it. Vim I use as terminal editor, and when I do work inside repo, reading diffs and programming in some languages (like C for example).

I really want to switch to only one editor, but whenever I try, I come to the point where I miss the feature of some other one of these 3. : ) I'm bit too weird when it comes to editors and configs...

What are those arguments?

it's not the contents of the release that's the story here, but more the fact there is a release after a long period of Inactivity from the dev side of it. And also the fact it's still in Beta

Some editors which are released slowly and liked by few is ok. I am using Sublime 3 in beta for very long time. Sometimes it gives popup to upgrade which I do then. Else it is fine, doing the job at hand without latest and greatest feature which I am not using.

Certainly more than if ST were to be abandoned. In fact the main reason why VSCode and Atom exist is probably Sublime being closed source.

I have donated to organizations such as Wikipedia, FSF, EFF, etc. so in my case software libre it's not about saving money. I acknowledge that making money with a software libre project it's still a challenge.

It's been around for 20 years and works on Windows/MacOS/Linux.

[1] https://www.ultraedit.com/

1) It's not as slow as it used to be.

2) The vim binding plugins are superior.

Check out our changelog: https://github.com/VSCodeVim/Vim/releases/tag/v0.8.0

Disclosure: I am one of the developers for VSCodeVim, but I am legitimately excited about all the features we've been adding recently.

[1] https://chrome.google.com/webstore/detail/caret/fljalecfjcio...

For example, I just started using Gogland and it is much better than ST with whatever plugins I could find. And it's unfortunate because I really like the convenience of using ST for all my different languages I use at work, but I'm just so much more productive with Gogland that I'm going to make a hard switch.

Once you use intelliJ IDEA, it's very hard to switch again, because there's so much that you feel missing...

Go to Preferences > Tools > External Editors

Add a new entry called Sublime Text

Turn off ‘Open Console’

Set program to /Applications/Sublime Text.app/Contents/SharedSupport/bin/subl

Set Parameters to $FilePath$

I'm used to a lot of different ways of doing search/replace (IDEA, emacs, vim to name a few) but somehow, my brain doesn't seem to be able to become fluent with ST's approach.

https://github.com/i-tu/Hasklig

The lack of them is one of the reasons I'm considering switching to VS Code.

Can someone post how it look like? I am curious.

http://imgur.com/a/6NOBG

This is great. Didn't feel right at all to see <NUL> in the code after doing multi line pasting.

Looking back 4 years later I'm certainly glad I didn't hold off until St3 was officially out.

https://en.m.wikipedia.org/wiki/Osborne_effect