JPS could do a better job of keeping in touch with the community, if only to post "I am still alive" from time to time. So many similar projects have dies on the vine that when an author goes very quiet for an extended period of time, its a bit troublesome.
That is such a great news. Can't wait to try out the indexed Goto Definition feature. The current implementation is not so great. Hoping this will be improved with the new version.
I bet he wasn't amused by the number of ST2 users who got the ST2 beta and were using it without having got round to paying, in fact I'd bet this was the majority. The trouble with honour systems is that not enough people are honourable.
Goto definition and goto symbol? Oh my! Quick test and it works fairly well already. Definitely some enhancements I want (text preview) but I can already tell this will be a glorious upgrade.
Can't quite figure out this goto definition thing, though of course I'm trying it using a dynamic language, JavaScript. Was praying he worked some secret SublimeText magic into it :/
I am certainly concerned that they might give it the official arse.
The only thing that gives me hope is that the Pro fits a small but important niche in the overall ecosystem: a system better suited for the developers of iOS applications than the iMac is.
The initial version of ML was terrible on my 2008 MBP but they made performance enhancements and now 10.8.2 works fine. Spending $50 for gb/RAM didn't hurt of course (best investment of my life btw).
I'll second that. I put an SSD into a 'poor performing' laptop as a stop gap before buying a new laptop. I still haven't bought that new laptop 2 years later.
I remember when TextMate's author announced he started working on TM2 and that it would be $big_cat_name-only. I had a heated debate in the comments because I thought paying a full system upgrade (the computer could not run $big_cat_name) was too much for getting a free upgrade to a simple text editor.
I eventually bit the bullet and bought a new Mac. But TM2 never came and I paid thousands of euros for nothing.
Since then I've moved to Linux at home and I use Vim everywhere. For some reason, I can't imagine being unable to build Vim 7.4 on this machine.
And now that I feel very comfortable in Vim, I can't imagine switching to ST or back to TM.
I love the addition of better pane management. With a few slick keyboard shortcuts I think this sounds like a nice improvement to working with multiple files in a project. If it's implemented in a similar way to my beloved tmux, I'll be loving this feature.
I was thinking the opposite. I'm glad he's charging for upgrades, and charging a decent price for something some developers use all day everyday. I hope this will enable him to continue developing ST.
I'm growing fairly dependent on plugins, though -- I hope the new API isn't too hard for plugin devs to upgrade. Although with most plugins hosted on Github these days, compat is just a pull request away.
So you don't think a ~640% pricing increase rather large? I'm not saying the software isn't worth $70. But relative to it's previous price, I think it's a pretty significant increase.
Edit: My mistake - I just can't read. It was an $11 increase in price.
I'm pretty sure you are right, I don't remember it being $11 because I could have afforded that but $50 was harder to do at the time I was looking into it
It's not a pretty big jump. It's only slightly more than what the author needs to keep up with economic inflation. Assuming 3% inflation per year, Sublime would have costed 59*1.03^5=68.40 USD now.
More like $20 after you write it off on your taxes. Seems like a steal to me. Intuit wants $170 to upgrade QuickBooks, Adobe wants $200 to upgrade Photoshop, and this little text editor adds more to my bottom line productivity than either.
My pet peeve with editors is how they handle files changing underneath them. I do this regularly enough (eg I might make a quick change using vi, source control update), there could be ssh or sshfs involved, or another tool might be better for doing whatever it is that I wanted.
Emacs has been the only editor that has never lost a change for me. Whenever you try to make a modification it checks the underlying file is as expected, and tells you if not. I tried SL2 and it quite happily ignored the fact that the file had changed. I'm also evaluating AppCode and it has perhaps the worst behaviour - it silently updates the editor window. But some of the time it doesn't notice the change and hence overwrites it. Consequently you can't trust the editor.
gedit also notices changes proactively (compared to emacs' reactively) but I don't use it regularly.
Vim produces a warning whenever you focus on the window, asking if you want to keep your current work or load the changed file. If you keep your work, it reminds you yet again if you attempt to save over the changed file, just in case.
You can find out the (highlighted) differences between the in-memory buffer and the on disk version one via "Show Unsaved Changes" on the context menu.
When I halted my evaluation of SL because of this issue I did send them feedback about it, but never got a response. I did have some other far lesser concerns like wasted space if you turned line number off.
> I tried SL2 and it quite happily ignored the fact that the file had changed.
Weird. I use Sublime Text 2 exclusively across all three platforms. Whenever an open file changes (e.g. I sync to Perforce), it pops up a modal dialog box when I bring that file's tab back into focus. If you're referring to a file that's changed in the background as you're actively editing it, I admit I haven't tried that.
Yes, that what's I was describing. It works just fine. When I tab back to Sublime, I get the "<filename> has changed on disk. Do you want to reload it?" modal dialog box. (If there are no unsaved changes in the Sublime buffer that could be clobbered, it just reloads the file silently as you'd expect.)
My test just now was on Windows, but I use it regularly on Mac and Linux as well, and I'm pretty sure I would have noticed if it silently clobbered changes like that. You're sure you had unsaved changes to the Sublime buffer for the file when you conducted your test?
I'm using btrfs. In any event it sounds like my test must have been flawed. Perhaps I didn't notice it doing an auto-reload.
I don't know what mechanism SL uses. A lot of my current work is using sshfs with editing happening on Linux and the endpoint being MacOS. inotify won't work for that, but more paranoid and repeated stats will.
The only problem along these lines I've had with it is in renaming files, where it doesn't appear to be locking onto the inode and the previous-named file still remains in editor and can be saved with the old filename. OOB edits do get reflected back into the editor somehow, though.
If the fine hasn't been changed in SL2, it just reloads it with a message displayed in the status bar. If it has been edited in SL2, it asks if you want to reload the file.
Python's "2to3" utility helps a lot with the mechanical parts, like spotting renamed modules or print statements. After that, it's a chore of hunting down small semantic changes involving strings. Since everything in Sublime Text should be using the same flavor of string, at least that part should be straightforwards.
Coming from someone who has never used or tried Sublime Text, how does this compare to Vim in general? It's taken quite a while to grow familiar with Vim, is it worth the learning curve to ditch it now and try Sublime? Are the two really that different? A lot of what I'm seeing looks like things that can be done in Vim, but I might be missing something.
I'm a vim/textmate user and I found sublimes UX to be lacking polish and the UI overall needed work.
I like textmates uniform OSX style and VIMs uniform terminal style, using the "Tomorrow" theme on both [1].
Although I'm also a part designer so the aesthetics matter to me as much as functionality. If you're measuring functionality I can't imagine sublimes better than VIM.
With a few basic JSON edits I was able to make Sublime look pretty sexy. Its spartan appearance matches it's utilitarian nature. I find it very comfortable and trusty. I agree that TextMate has the OS X polish that I too prefer but it's development has stagnated a bit in comparison. There is definitely a place for ST right in the middle of Vim and TextMate. Heck, if the Sublime guys could whip up a better Dock icon that'd go a long way.
The vintage mode is excellent. It's the best emulation of vim that I've used.
Sadly I can't run ST2 on our work machines as the RHEL version we use has a libc (glibc?) that is too old. I'm unable to host my own libc due to a binary format change that is incompatible with the system dynamic loader.
Which ones have you tried? Vintage mode is most impressive considering it's so small (code-wise), but I don't find it particularly good at even the basics (a lot of commands have subtle behavioural differences).
It's better than IDEAVim, but certainly ViEmu and jVi are better. Maybe even Vrapper and XVim beat it too.
You can use a vim emulation mode in sublime so all your hard work wasn't for nothing but I believe some of the more advanced vim features don't work in sublime.
The advantage of sublime is that it works well out of the box and with package control it is very easy to install any package you may need.
If you decide to give it a try, try sublime 2 with package control (I believe the trial is still free for sublime 2).
Gvim always used to work fine for me when I was developing a C# system, the awkward thing was the naming conventions being broken for everything so I had to go on a renaming binge.
It's not just the advanced features. Even basic features are completely broken. Pressing undo several times can occasionally break out of undoing and start editing your document on your behalf - spewing a slew of "uuuuuu" into your document, which - guess what - ruins any hope you have of reverting back to the original document state.
Sublime works better out of the box and is arguably prettier. But if you like modal editing then Sublime may not be for you.
There is Vintage mode, but IMO it doesn't work very well. The differences are small but numerous, and it's very annoying when the behaviour doesn't match Vim's. Others have rightly pointed out that many advanced features are missing, but I'm not talking about those - I'm talking about your bread and butter navigation/editing commands.
To make matters worse, while there is the occasional pull request, official development of Vintage mode seems to be at a complete halt.
I purchased Sublime and really, really tried switching to it (I think I gave it about six months), but I had to switch back.
I'm in the same boat. I still think NERDTree, NERDCommenter, surround plugin, modelines and ability to use the same editor AND plugins in an SSH console is unbeatable combination. I can edit from my iPad with a bluetooth keyboard on my Linode VPS.
I really liked Sublime but VIM like a good pair of Levis' 501 never goes out of style.
I've tried it when the first public ST2 builds were released. I kept downloading new builds from time to time out of curiosity but I ended up removing it definetely a while ago.
What I liked: well, I didn't actually like anything beside the ease of modifying/adding keybindings.
Some of what I didn't like:
* The whole UI felt wrong from alpha to omega and overly gimmicky: the whole thing relied too much on the mouse and the things that relied completely on the mouse like the options in the search panel were poorly sized/designed. The many roundrects and shades and gradients created a mess that left a very bad impression.
* The underlying engine is very poorly used by ST: just activating vintage mode is enough to tap a lot deeper than the default UI lets you. The engine is great but it only shines when you try to use it as another app. That's weird.
Using Vim is a spoiler, I guess.
I can't reasonably tell you to not make the switch. I have no idea what knowledge you have of Vim but I can say that I find Vim not only extremelly more powerful than ST but also a lot better designed on almost all fronts.
Once the beauty of subsitutions, :global, ranges, Ex commands, text-objects and motions is ingrained in your brain, using ST2 may feel like using (a pretty) TextEdit. Hell, even folding is nicer in Vim.
In the last year, I had the impression that a bunch of people blogged about their decision to switch to ST2 from Vim. Each time, I felt that the blogger didn't use much of Vim to begin with so switching may have made some kind of sense. If you are reasonnably advanced, I don't think there's any reason to switch.
The UI looks very much like a programmer wrote it. But I can ignore the gradients and the Soda UI theme makes it look more like a native app.
But the find panel is the sole reason I cannot use ST2. Every time I bring it up I can't remember what button does what. And then I get stuck in the panel and have to click to get rid of it. Or hit escape.
But if I hit escape before hitting enter it assumes I didn't want to search after all and scrolls the viewport to somewhere random. Even though the term I wanted to search for is clearly highlighted on the screen.
It's a very very frustrating experience and even my co-worker who uses ST2 every day for the past year or two still gets tripped up by the find panel.
If I had a way to import the TextMate 2 find dialog into ST2 /3 I would buy a license.
Agreed, the find and replace UI in ST2 is extremely frustrating. The essential functionality is all there, but the changing behaviour of different keys depending on context drives me crazy, particularly the way you need enter vs. escape to get back to editing, and the meanings of F3 and Shift+F3 swapping depending on whether your last search was forward or backward. Also, it's silly that you seem to need to mess around with the mouse to change basic find options like case sensitivity or using regexes, and to set the locations affected when finding/replacing across files. Tidying up the keyboard shortcuts in this area would bring a huge benefit in usability for a relatively small change in behaviour, IMHO.
I'm a Sublime Text 2 owner, but the continued lack of a Linux/ARM build nor any announced plans for the same mean I won't be upgrading. It is a shame because I like the editor a lot, but if it doesn't work on all the platforms I use it ultimately has zero value to me.
Why do you need ST to be involved in building? I use ST for all text editing and then click the build button where ever it may lie - python script file, Xcode, or VisualStudio.
You do lose the ability to jump to the exact line an error is on which is a mild nuisance but nearly enough to make me stop using ST.
ARM devices are happening.. without having seen your codebase I can't speak for how hard it'd be to build for a new target, but given that you're targeting win32 and posixy systems already it seems achievable.
Wouldn't you much rather be the badass that works everywhere than snrk at a growing niche?
Sounds like a perfect business opportunity. Offer the author, say $50,000/year in exchange for being allowed to port and support the editor on Linux/ARM and take all the licensing profits from there. You only need to sell a few $79 licenses compared to the number of Android devices there.
A complex resource-hungry IDE is just what the Android platform has been missing.
While you're at it, add Common Lisp support. That is literally the #1 request on the announcement.
>Linux/ARM is bigger than iphone, apple, and dell combined.Android. It's sitting on a desk near you.
Most Android devices are sold free with contract or with low tier phones to people who don't care much about smartphones. As for Android tablets, they don't sell that well, period. That's the huge majority of Android users. A minor one is geeks like us, open source fans, etc, that prefer it to iOS. (And that still leaves tons of geeks preferring iOS).
You didn't even make it one whole sentence with a correct statement. You stink of an OSS troll in this thread.
There have been plenty of interest in Sublime Text 2 builds for Android, I've seen people ask about it for both the Exynos Chromebook and the jailbroken Surface RT.
Amazingly, I can use ALL of my desktop software (except VirtualBox) on Linux/ARM and it's just like using an Intel machine. The only thing missing are proprietary apps like ST that can't have an ARM build generate for it automatically.
Nope, I'll be upgrading! ST2 is great (even without ARM support). But I'll second the request for an ARM/Linux version. I just got my ARM Chromebook set up with Chrubuntu and I'm already missing ST2 (using Emacs for now ...).
I bought it when Sublime Text 2 came out of Beta, which wasn't all that long ago, was it? As somebody that very rarely buys tools, it's hard not to feel a little incensed.
It's $30. What sort of development are you doing that isn't worth $30 for the single tool that allows you to do it?
I can't imagine carpenters are incensed when Ryobi brings out a new $300 drill. You either buy the new drill, or you keep the old one. Nobody expects new hardware for free, why software?
Completely agree. If you don't need it, don't buy it. It's that simple. You can't shell out $30 for one of the most important parts of your development environment?
If you have an old drill and buy a new one, you own an old drill and a new drill. If you have old software and update it, you only have the new software.
In the first case, the value of your goods and of their use to you is more than just one drill.
In the second case, you end up paying more than the price of the newest software, for just the newest software.
From this, one could make the argument that the most fair upgrade price would be $11 - the difference between the old and new software.
By that argument, the best strategy is to hold off buying any software indefinitely until you are absolutely sure that there will be no future paid updates.
I don't see why that argument equals that strategy. It's an argument for expecting a specific price, not for waiting for a specific product or service.
"What sort of development are you doing that isn't worth $30 for the single tool that allows you to do it?"
I do light programming, mostly web stuff. Sublime certainly isn't the only tool that allows me to edit code, I used Notepad++ for years, and I'm sure there's a dozen other options. I also just use it as a regular old notepad.
I suppose what I'm saying is my expectation was that for a premium tool, I would be supported with updates and bug fixes for a longer period of time. I probably will buy the upgrade, but I would hope for a longer period of support with version 3. If this turns into a recurring payment model I may need to switch back to strictly free and open source tools.
It's not uncommon; Visual Studio's release cycle is around every two years.
To work out the math a bit, say the developer is looking to make 70k a year (which is quite low IMO, especially if you are self employed). If his release cycle is every two years, he needs to make 140k over one version. At $59 for S2, thats around 2400 sold copies over two years. Not a small number for a product that is tailored to such a niche market. Also considering that there comes a point where the purchases trail off, so the developer needs to find a way to sustain an income. Upgrades seem like a very reasonable way to do that.
With S3, if the developer wanted to offer a reasonable way to allow S2 owners to upgrade at a discount, it comes at a loss of income for the next two years. Given that the amount of people who would buy the editor have already bought S2, so the pool of possible purchasers decreases. So it seems like a reasonable balance to allow that discounted upgrade, while increasing the full price to make up for the loss of new purchasers.
Are these changes really worth the "3.0" tag? Goto to symbol is great, but all other bullet points taste like what I expected 2 to have once it left beta (basically, speed and not letting plugins crash my session).
Isn't this a clever way to make users buy into a paid upgrade for a stable version of an editor they already bought?
Yep, my thoughts exactly. Sublime is one of the few pieces of software that I rely on that has not only never let me down (so far!), but has really pleasantly surprised me on several occasions, saving my ass when I thought I'd just lost a lot of work.
For example, the "autosave" can be pretty handy. You enter some text into a tab, close sublime. You have no annoying dialogs asking you to save the file etc and the comtent is saved so that it is available in the same state when you reopen.
If not for the save your ass by not losing work bit, I like it for not being annoying.
I actually use "autosave" as a temporary clipboard. When I need to keep something over multiple days but don't need it forever (i.e. big, hairy command strings) then I just open a new tab and paste it in. That way I can continue to copy/paste the command whenever I need it and as long as I don't close that tab I'm good to go. :)
- I run it on Linux, and had an unstable distribution for a while. I had a couple of occasions where the OS hard-locked, but on reboot Sublime started right back up to its last state -- including unwritten changes to multiple files.
- During a move to a new distribution, once I got my old /home remounted, Sublime amazingly did the right thing and again reloaded all of its state from the last operating system. I was expecting to have to re-open 30+ tabs/files and redo all of my user settings. Nope, Sublime did the right thing again.
- An update on my current OS has caused a problem with fuse which is causing my development directory to get unmounted on a regular basis. Sublime doesn't have a problem with this; any files that it loaded from the now-unavailable mount point are still there, the content is still all there, it doesn't freak out, it just marks the file as dirty (letting me know I need to remount that directory again).
- An rsync went afoul and nuked a pile of changes to a local development copy of a site. I was able to retrieve a bunch of my work from Sublime's open tabs.
None of these things are really examples of brilliant new engineering, but, in my experience they're all the kinds of details that too many other programs don't get right. Sublime just always seems to do what I would expect software to do in 2013.
That, plus ctrl-D is beautiful.
If I had to think of something I don't like about it, about the only things would be that occasionally the autocompletion is a nuisance, and occasionally I'll need to open a really really big file and a plugin causes it to stall for a bit. It sounds like the latter problem has been taken care of now in v3.
If Sublime were a bro, I'd always buy his beer. Instead, I'll be more than happy to pay the upgrade price.
I wouldn't argue that its "clever". Its a direct and honest way of asking people to pay for Sublime Text.
I'm happy to pay Jon as long as he keeps cranking out fast, high-quality software. Think of it as a subscription where you still own the software if you want to get out of it.
It's not a direct and honest way of asking people to pay for Sublime Text - it's an indirect way of asking people to continue to pay for something they thought they'd already bought.
I paid for Sublime Text 2 with the expectation of continued support of the quality we had during beta, but instead we have waited months for bug fixes which have never arrived. ST2 was essentially abandoned after it left beta, and now we find our money hasn't gone into supporting the product we paid for, it's gone into funding the next one.
As a developer I know this makes excellent business sense, but as a user it feels like I've been tricked. The changelist looks more like a point release, but one we have to pay another 50% for in the hope our bug reports will eventually be acknowledged. Given the past 6 months I have no confidence that'll happen.
Perhaps I'm being unfair - after all, I use ST2 all the time, and I've certainly got my money's worth out of it, even with the bugs - but something about this just doesn't feel right.
Good point about expectations. I wonder if the problem really is that it was in beta for so long, instead of being released in a slightly more buggy state, and then having most of the bugs fixed in point releases after that.
I paid for Sublime Text 2 with the expectation of continued support of the quality we had during beta, but instead we have waited months for bug fixes which have never arrived.
Rationally, as a software guy, this seems somehow unfair. After all, even as it was launched and without any further changes, ST2 is a good product at a low price.
But the reality is that I feel the same way as radiac. When I chose to spend real money on a text editor -- not exactly a field where the free competition is lacking -- I did so because I wanted to support and encourage a project that did seem to have a lot of nice little touches and did seem to keep coming out with them. The obvious and abrupt end of the stream of incremental updates the moment ST2 went final does irritate me.
Unfortunately, contrary to the post I just read about how stable ST2 is, I have seen irritating crashes that stopped me using it for some work, and I haven't seen a bug fix even for that, nor any other improvement since I sent the money. I probably won't pay for ST3 at this point, because at least now I've figured out what does crash ST2 and how to avoid it, and fairly or otherwise, the assumption in the back of my mind is going to be that ST3 might make a few minor improvements of the kind we used to get anyway, but if it has any sort of crash or data loss bugs they won't get fixed.
I felt this way about Ultra-Edit32 for a long time on Windows. I bought in college, and I believe it had a "... and future upgrades are automatically free" clause. It made me have a LOT of faith that this would be a useful and awesome product, and I was a happy user for many years. (In a sense, I bought it twice, as I asked my employer to buy it for me later.)
As a prospective user of Sublime Text (3, now), it's interesting to think about how I would feel had I bought ST2 a year ago, and now felt compelled to upgrade. The price is semi-negligible, in terms of how much one pays for a quality tool -- it's a fraction of the price of Komodo IDE or PyCharm, for example -- but the hassle is still annoying.
As Silhouette points out, it really makes one wonder about how long "support" (bugfixes, etc) will last for the current version. I think one of the more interesting questions to arise from this thread has been what the difference is (or should be?) between a point release (vN.5) and version N+1.
If you subscribe to versioning schemes like for instance semantic versioning [1], then the major version number must be incremented "if any backwards incompatible changes are introduced to the public API". In that sense, the change from Python 2 to 3 could warrant it.
I'd rather Jon ask for more money by ticking the version up and cranking out stuff than let the editor fester like TextMate 2.
That's what I view as honest, "I'm going to work on ST3 to convince you that its worth buying."
I haven't faced the same quality issues you speak of. TM2 has been rock solid for me. The only thing that never felt right was the theme (install Soda) and icon (Yuck, reminds me of Comic Sans)
I'm not saying that he should keep pumping out new features for ST2 - it's totally fair to draw a line under it on the day it leaves beta and say "no more features". My complaint is that he took ST2 out of beta while people were still complaining about bugs, and has subsequently only issued one bugfix release.
As both a user and a developer, I don't think it's unreasonable to expect paid software to get support and bugfixes for a while - at least until the next version leaves beta. "Pay an extra 50% and maybe I'll fix the bugs" doesn't seem fair.
The editor was already pretty stable, but maybe not the plugins, which are optional. I'd agree that the price is a bit high to upgrade, but for people like me who didn't own it yet, now is a good time to buy.
But if you don't think this upgrade is worth it, do you want to invest in a product that is likely to make you pay for upgrades you don't think are worth it in the future?
I think it is a valid point. If it provides the value to you.
I don't get these price discussions. If you earn your money by programming, I think it is crazy to be cheap on your tools if you can get the job better done using them.
If you program occasionally, then use some free open source editor.
People on construction sites don't use the cheapest tools available for a reason. If you use it to earn money, you shouldn't be short sighted.
The valid point is "it's worth it to me," not "lots of other things with less value cost as much or more and I willingly pay for those, too."
If you tell me a Ford Taurus costs $40,000, justifying that by telling you I spent $100,000 on a broken bike doesn't make the former a good deal.
The way I see it, $70 on its own is meaningless. A lot of people are taken aback because it feels like $70 for an advanced text editor. And in many ways, it is that with some IDE flair built-in.
I own a license and honestly still find myself in Notepad++ for a bunch of things. As a professional programmer, I have come to the conclusion that for my purposes it's overpriced. Your mileage ... well, it should vary.
I'm not sure why you go from "provides even less value" to "that 'even less value' < $30".
A $30/month SaaS app is usually paid for because it saves/brings value of $100+ per month to your tasks. A good editor easily brings more value to a developer.
Actually my comment there ignored "value" altogether, really. The value is irrelevant.
My point is you can't quantify the value or justify the cost in this way. Surely, a $40,000 Ford Taurus provides more value than the $100,000 broken bike, but that doesn't mean the Ford Taurus is priced appropriately for needs.
I'd been wondering about the recent slow pace of updates, but I shouldn't have doubted. I've been consistently delighted by the quality of Sublime and the frequency with which it improves. For the amount of work I do with it and its quality premium over competing tools, at least for the features I value, it feels underpriced (on a US salary).
I'll happily pay for the upgrade if it keeps the author cranking away at a similar pace.
Well considering the large development in terms of plugins and this is currently a BETA, we'll have to wait and see how many new features come out with ST3 to justify the 3 tag. Or it can become a Firefox and have ST18 in a couple of years.... ;-)
Might be worth pointing out that the version number is no longer on the application name. There was "Sublime Text 2" and now there's just "Sublime Text".
>Goto to symbol is great, but all other bullet points taste like what I expected 2 to have once it left beta (basically, speed and not letting plugins crash my session).
I bought ST2 without expecting all these features. Taking the effort to add out-of-process plugins? That's more that the TextMate guy has done in all 6 years of dabbling with 2.
On top of that, it has other nice stuff I want. It might be OK calling it 2.5, but it's not a scam by any imaginable stretch of the word.
>Isn't this a clever way to make users buy into a paid upgrade for a stable version of an editor they already bought?
No. Did you find ST2 any less stable than any other editor out there? I use it for a year for working on 3-4 different languages and it never has crashed on me.
So, I appreciate the cynicism but it's misguided here.
^ this reply can be summarized as "turning on the fan to spread shit on everyone else".
This is a discussion about sublime, not other editors. And if other editors have shortcomings, it's not an excuse.
I also think that after paying for software the least you can expect is relatively bug-free code or quick updates to fix them, and a reduced number of crashes. That is, for software that has left beta to be labelled stable.
The change from python 2.6 to 3.3 would probably affect some plugins, so one could reason that, by adding the "3.0" tag, plugin creators would more easily accept the need for porting.
I am disappointed to see that Vintage mode hasn't really been touched at all for this edition. It's what is holding myself (and likely others) back from switching away from Vim. Unfortunately, development of Vintage mode seems to have stopped (the repository hasn't changed for about six months).
not really, but the man spent all his time on S3 development, I think it's the reason that we haven't seen any progress in vintage mode. With S3 beta released, I guess he doesn't need to stick to it every second any more.
As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger?
I've seen how GDB works, and debugging this way seems much less productive. You don't see your whole source code, and you don't constantly see the values of watched or local variables, etc... Is there a different debugger you use for this task when developing using only a text editor (vim/emacs/sublime)?
>As someone who only used IDE debuggers all his (short) programming career, I was wondering, how do you debug without a visual debugger?
I'd ask the reverse of you. Why do you spend time in a debugger at all? For 99% of the bugs logical thinking and a few printfs work faster and better ran blindly running around setting breakpoints and examining values.
Though learning how to use the debugger is a good skill to learn, these days I don't know anyone around me who has ever used a debugger, or even finds a use for it. I think the best tools of our age are really REPL's, which allows you to test out your guesses/hypothesis in the form of snippets.
Personally I have probably used a debugger 5-6 times in my whole programming career, these days I hardly find a use for it.
Depends on your use case. If you're trying to find an issue in Java code running on an app server somewhere where you're not allowed to update code (say, if you work in B2B and it's a customer site), being able to remote debug does wonders.
Debuggers are handy for the last 1% of bugs. And anyway there is nothing about debuggers that precludes logical thinking or requires "blindly" placing breakpoints.
Adding printf statements implies recompiling or rerunning code. A good debugger lets you set breakpoints against your app while it runs, and have the breakpoint log a message instead. So even if you just want to log messages at certain spots, a good debugger works better (to say nothing of following program execution through long sequences of source code files, which is even handier when the source code is some open source component that you didn't write).
I agree that printf works better than "blindly running around setting breakpoints", but so does pounding a 12-pack of beer and then hitting yourself in the face with a mallet until the solution comes to you.
On the other hand, learning to use a modern, advanced debugger and then applying that skill along with some of that logical thinking can be extremely effective in finding the cause of bugs as quickly as possible.
For languages like Objective-C or Java, I think the 'real men don't need a debugger bro' attitude is nuts. It is different for a lot of newer and/or more dynamic programming languages, which simply don't have debuggers anywhere close to as powerful as those of IntelliJ or Xcode/lldb.
It can be nice to pause the execution and think, then continue one line at the time and really see what is happening.
Also I hate writing prints over and over. Sometimes it is imply faster to put a breakpoint, look at the value and then pop it away. As opposed to manually writing the print, then check, and then removing it.
I think it very much depends on the language and platform/environment.
I've been programming professionally for nearly 20 years, in languages ranging from Perl to C/C++ to Javascript, and the only times I've used GDB in the last 15 years have been when C/C++ code is segfaulting and I want a stack trace. The rest of the time I use print/printf statements. I've built some pretty successful software this way, some of which you've probably heard of or used.
On the other hand if I were coding exclusively in C/C++, or Java, or using an IDE for my work, I might use a debugger more.
I think the use of the word printf makes which ones we're discussing pretty clear.
I'm getting up there too. And I know lots of older programmers with very bad habits. Many who have also working on household names. Age+popularity != skill/quality.
Doing that in anything but interpreted and micro applications seems like a massive waste of time and effort(both placing the printfs, recompiling, removing them recompiling.
We've all done it. It doesn't mean its a good way to do it.
And like I said above it can introduce bugs into your code doing so. I remember one case where a printf for debugging changed the memory in such a way as to make an uninitialized variable work. After testing when the printfs were removed the application would stop working.
Introducing code into your code base with the intention of removing it later when there is an easy way to not do so is asking for trouble.
I use Vim/Sublime for rote text editing and scripting languages. For most statically typed languages (C, C++, C#, Java, Objective-C and so on) I tend to use an IDE with a Vim emulator.
But honestly, visual debugging is nice and all but I don't know if the debugger is really the biggest loss of not using an IDE - for me it's more the code completion, navigation and refactoring support I'm after. You can get most of that going pretty well with Vim but it's a bit of a hassle.
I found that I wrote much better code once I ditched the IDE debugger, and stopped writing enterprise code... Perhaps the latter outweighs the former in terms of impact.
Firing up GDB for those rare segfaults which I don't immediately know the cause of (the last 2 lines I wrote, usually) gives me a stack trace very quickly, and lets me dump the values of the variables in that frame. I rarely need more. That wasn't the case back in my enterprise days.
GDB is very powerful, check out its integration with emacs for example (not something I've used).
When I moved from Windows to Linux development I was concerned how that would affect me. Turns out not so much, I just don't debug as much on Linux :)
IDE debuggers make it far too easy to press F5 and see what happens, make a change, press F5 etc without really thinking about what's happening. Iterative coding gone bad.
The only time I use GDB is for the occasional segfault that I can't figure out from back-stepping a few revisions, and it always nails it (which is more than can be said for MSVC)
I'm also Vim user who has considered jumping to Sublime several times, but never quite managed to achieve escape velocity. (Though I hadn't realised until now that the Vintage package is an open repository)
While a couple of things are missing, mostly it's that things don't work properly.
Some random things off the top of my head:
* No block cursor (the block cursor plugin doesn't really work)
* When you switch between files, it keeps jumping back to insert mode, but you don't immediately notice (especially since there is no block cursor). There's a setting, but I've never been able to make it work.
* Autocomplete and the dot command don't work together
* Macros are flakey
* Visual mode and the dot command don't work well together
While I agree that vintage lacks some refinement, the source for the plugin is sitting in your sublime directory and is fairly easy to hack on. Things like the one-off cursors are fairly easy to fix. I'm not sure what you mean about switching files; I don't notice that particular problem. Do you have '"vintage_start_in_command_mode": true' set in your config?
As far as a vim-style editing plugin goes, vintage has by far been the best I've encountered. It's one of the few where it's fairly straightforward to add in the hacky things I've done to vim and still get a similar experience.
The code is quite nice indeed, and oh so small for a vim emulator - I've contributed a significant chunk to XVim which is positively massive in comparison, so I have some frame of reference.
The problem is that if you want all the fixes you pretty much have to compile a version with all the pull requests yourself as they don't get merged into mainline in a timely fashion. I would personally be much more keen to fix these things if I knew that my efforts along with everyone else's were expediently dealt with.
I do have vintage_start_in_command_mode set, but that apparently only works on startup (I read somewhere on the forums that it's a per-file setting, whatever that means).
Vintage is pretty good, but I don't agree that it is top shelf - ViEmu and jVi are both better Vim emulators IMO, and Vrapper and XVim are better in at least some regards.
For me it's the flexibility of window splits. In Vim I use both vertical and horizontal splits constantly, sometimes having 6 open at a time to deal with, for example, a Rails model, controller and view along with a CSS and JavaScript file and associated tests. Sublime has some window splitting but compared to Vim (or Emacs) it is pretty weak. If that is ever changed I'd consider switching.
With the upgrade to python, anyone relying heavily on packages is definitely have to upgrade. Not may package devs are going to want to maintain ST2 AND ST3 packages.
I have been curious for a while about how ST 2|3 is architected. I know it uses C++ but how does it work so well as cross-platform application. Does that stem from being built in C++? What UI framework does it use?
373 comments
[ 5.4 ms ] story [ 161 ms ] threadAnd I thought 2 development has slowed down after release (sparse new dev builds etc).
We'll have Sublime Text 3 before Textmate 2 beta 2.
I'm also amused that he's now restricting the ST3 BETA to registered users only, where ST2 had a long BETA period.
This has been available (using cscope) on VIM and Emacs for ages.
Looks like I might have to bite the upgrade bullet this year.
The only thing that gives me hope is that the Pro fits a small but important niche in the overall ecosystem: a system better suited for the developers of iOS applications than the iMac is.
More cores, more RAM, more GPU grunt to drive more screens.
I eventually bit the bullet and bought a new Mac. But TM2 never came and I paid thousands of euros for nothing.
Since then I've moved to Linux at home and I use Vim everywhere. For some reason, I can't imagine being unable to build Vim 7.4 on this machine.
And now that I feel very comfortable in Vim, I can't imagine switching to ST or back to TM.
http://www.henriquebarroso.com/my-top-10sublime-2-plugins/
Some of my favorites are there! If you haven't done so, check it out too!
That's a pretty big jump. Not saying it's not worth it.
I'm growing fairly dependent on plugins, though -- I hope the new API isn't too hard for plugin devs to upgrade. Although with most plugins hosted on Github these days, compat is just a pull request away.
Edit: My mistake - I just can't read. It was an $11 increase in price.
edit: it appears I was right and I just misread: the price increased from $59 to $70.
Although it's a silly error, I made the same one, and I know that I bought ST for $59. So I think the problem here is with the wording, not with us.
I wonder if this also means official repositories.
Emacs has been the only editor that has never lost a change for me. Whenever you try to make a modification it checks the underlying file is as expected, and tells you if not. I tried SL2 and it quite happily ignored the fact that the file had changed. I'm also evaluating AppCode and it has perhaps the worst behaviour - it silently updates the editor window. But some of the time it doesn't notice the change and hence overwrites it. Consequently you can't trust the editor.
gedit also notices changes proactively (compared to emacs' reactively) but I don't use it regularly.
Surely not hard to implement (if it's easy to say, it's easy to code, right??)
Weird. I use Sublime Text 2 exclusively across all three platforms. Whenever an open file changes (e.g. I sync to Perforce), it pops up a modal dialog box when I bring that file's tab back into focus. If you're referring to a file that's changed in the background as you're actively editing it, I admit I haven't tried that.
I don't know what mechanism SL uses. A lot of my current work is using sshfs with editing happening on Linux and the endpoint being MacOS. inotify won't work for that, but more paranoid and repeated stats will.
[0] http://kate-editor.org/about-kate/
If the fine hasn't been changed in SL2, it just reloads it with a message displayed in the status bar. If it has been edited in SL2, it asks if you want to reload the file.
Oh god, I've got some plugin fixing to do..
When I tell people how much I love ST2, Package Control is definitely responsible for some of that love.
I like textmates uniform OSX style and VIMs uniform terminal style, using the "Tomorrow" theme on both [1].
Although I'm also a part designer so the aesthetics matter to me as much as functionality. If you're measuring functionality I can't imagine sublimes better than VIM.
[1] https://github.com/chriskempson/tomorrow-theme
http://www.sublimetext.com/docs/2/vintage.html
Sadly I can't run ST2 on our work machines as the RHEL version we use has a libc (glibc?) that is too old. I'm unable to host my own libc due to a binary format change that is incompatible with the system dynamic loader.
It's better than IDEAVim, but certainly ViEmu and jVi are better. Maybe even Vrapper and XVim beat it too.
The advantage of sublime is that it works well out of the box and with package control it is very easy to install any package you may need.
If you decide to give it a try, try sublime 2 with package control (I believe the trial is still free for sublime 2).
There is Vintage mode, but IMO it doesn't work very well. The differences are small but numerous, and it's very annoying when the behaviour doesn't match Vim's. Others have rightly pointed out that many advanced features are missing, but I'm not talking about those - I'm talking about your bread and butter navigation/editing commands.
To make matters worse, while there is the occasional pull request, official development of Vintage mode seems to be at a complete halt.
I purchased Sublime and really, really tried switching to it (I think I gave it about six months), but I had to switch back.
I really liked Sublime but VIM like a good pair of Levis' 501 never goes out of style.
What I liked: well, I didn't actually like anything beside the ease of modifying/adding keybindings.
Some of what I didn't like:
* The whole UI felt wrong from alpha to omega and overly gimmicky: the whole thing relied too much on the mouse and the things that relied completely on the mouse like the options in the search panel were poorly sized/designed. The many roundrects and shades and gradients created a mess that left a very bad impression.
* The underlying engine is very poorly used by ST: just activating vintage mode is enough to tap a lot deeper than the default UI lets you. The engine is great but it only shines when you try to use it as another app. That's weird.
Using Vim is a spoiler, I guess.
I can't reasonably tell you to not make the switch. I have no idea what knowledge you have of Vim but I can say that I find Vim not only extremelly more powerful than ST but also a lot better designed on almost all fronts.
Once the beauty of subsitutions, :global, ranges, Ex commands, text-objects and motions is ingrained in your brain, using ST2 may feel like using (a pretty) TextEdit. Hell, even folding is nicer in Vim.
In the last year, I had the impression that a bunch of people blogged about their decision to switch to ST2 from Vim. Each time, I felt that the blogger didn't use much of Vim to begin with so switching may have made some kind of sense. If you are reasonnably advanced, I don't think there's any reason to switch.
But the find panel is the sole reason I cannot use ST2. Every time I bring it up I can't remember what button does what. And then I get stuck in the panel and have to click to get rid of it. Or hit escape.
But if I hit escape before hitting enter it assumes I didn't want to search after all and scrolls the viewport to somewhere random. Even though the term I wanted to search for is clearly highlighted on the screen.
It's a very very frustrating experience and even my co-worker who uses ST2 every day for the past year or two still gets tripped up by the find panel.
If I had a way to import the TextMate 2 find dialog into ST2 /3 I would buy a license.
You do lose the ability to jump to the exact line an error is on which is a mild nuisance but nearly enough to make me stop using ST.
Damn! There goes the whole of the Linux/ARM community!
ARM devices are happening.. without having seen your codebase I can't speak for how hard it'd be to build for a new target, but given that you're targeting win32 and posixy systems already it seems achievable.
Wouldn't you much rather be the badass that works everywhere than snrk at a growing niche?
Android. It's sitting on a desk near you.
A complex resource-hungry IDE is just what the Android platform has been missing.
While you're at it, add Common Lisp support. That is literally the #1 request on the announcement.
Most Android devices are sold free with contract or with low tier phones to people who don't care much about smartphones. As for Android tablets, they don't sell that well, period. That's the huge majority of Android users. A minor one is geeks like us, open source fans, etc, that prefer it to iOS. (And that still leaves tons of geeks preferring iOS).
If you need any proof that the majority of Android users are not that technical, just check these "relative number of active devices": http://developer.android.com/about/dashboards/index.html
Half a year later, only 10 percent have the latest release. And over 50% are two releases behind.
Neither the majority not the minority of Android users are much likely to buy a programmers' editor for their Android phone or tablet.
There have been plenty of interest in Sublime Text 2 builds for Android, I've seen people ask about it for both the Exynos Chromebook and the jailbroken Surface RT.
Amazingly, I can use ALL of my desktop software (except VirtualBox) on Linux/ARM and it's just like using an Intel machine. The only thing missing are proprietary apps like ST that can't have an ARM build generate for it automatically.
Why different prices based on when the purchase date?
I can't imagine carpenters are incensed when Ryobi brings out a new $300 drill. You either buy the new drill, or you keep the old one. Nobody expects new hardware for free, why software?
In the first case, the value of your goods and of their use to you is more than just one drill.
In the second case, you end up paying more than the price of the newest software, for just the newest software.
From this, one could make the argument that the most fair upgrade price would be $11 - the difference between the old and new software.
That doesn't work.
I suppose what I'm saying is my expectation was that for a premium tool, I would be supported with updates and bug fixes for a longer period of time. I probably will buy the upgrade, but I would hope for a longer period of support with version 3. If this turns into a recurring payment model I may need to switch back to strictly free and open source tools.
To work out the math a bit, say the developer is looking to make 70k a year (which is quite low IMO, especially if you are self employed). If his release cycle is every two years, he needs to make 140k over one version. At $59 for S2, thats around 2400 sold copies over two years. Not a small number for a product that is tailored to such a niche market. Also considering that there comes a point where the purchases trail off, so the developer needs to find a way to sustain an income. Upgrades seem like a very reasonable way to do that.
With S3, if the developer wanted to offer a reasonable way to allow S2 owners to upgrade at a discount, it comes at a loss of income for the next two years. Given that the amount of people who would buy the editor have already bought S2, so the pool of possible purchasers decreases. So it seems like a reasonable balance to allow that discounted upgrade, while increasing the full price to make up for the loss of new purchasers.
Try Googling "Richard Stallman".
Or simply reflect upon the fact that > 95% of the software used by the author of ST to create it was free to him.
Isn't this a clever way to make users buy into a paid upgrade for a stable version of an editor they already bought?
If not for the save your ass by not losing work bit, I like it for not being annoying.
- I run it on Linux, and had an unstable distribution for a while. I had a couple of occasions where the OS hard-locked, but on reboot Sublime started right back up to its last state -- including unwritten changes to multiple files.
- During a move to a new distribution, once I got my old /home remounted, Sublime amazingly did the right thing and again reloaded all of its state from the last operating system. I was expecting to have to re-open 30+ tabs/files and redo all of my user settings. Nope, Sublime did the right thing again.
- An update on my current OS has caused a problem with fuse which is causing my development directory to get unmounted on a regular basis. Sublime doesn't have a problem with this; any files that it loaded from the now-unavailable mount point are still there, the content is still all there, it doesn't freak out, it just marks the file as dirty (letting me know I need to remount that directory again).
- An rsync went afoul and nuked a pile of changes to a local development copy of a site. I was able to retrieve a bunch of my work from Sublime's open tabs.
None of these things are really examples of brilliant new engineering, but, in my experience they're all the kinds of details that too many other programs don't get right. Sublime just always seems to do what I would expect software to do in 2013.
That, plus ctrl-D is beautiful.
If I had to think of something I don't like about it, about the only things would be that occasionally the autocompletion is a nuisance, and occasionally I'll need to open a really really big file and a plugin causes it to stall for a bit. It sounds like the latter problem has been taken care of now in v3.
If Sublime were a bro, I'd always buy his beer. Instead, I'll be more than happy to pay the upgrade price.
https://www.sublimetext.com/buy
I'm happy to pay Jon as long as he keeps cranking out fast, high-quality software. Think of it as a subscription where you still own the software if you want to get out of it.
I paid for Sublime Text 2 with the expectation of continued support of the quality we had during beta, but instead we have waited months for bug fixes which have never arrived. ST2 was essentially abandoned after it left beta, and now we find our money hasn't gone into supporting the product we paid for, it's gone into funding the next one.
As a developer I know this makes excellent business sense, but as a user it feels like I've been tricked. The changelist looks more like a point release, but one we have to pay another 50% for in the hope our bug reports will eventually be acknowledged. Given the past 6 months I have no confidence that'll happen.
Perhaps I'm being unfair - after all, I use ST2 all the time, and I've certainly got my money's worth out of it, even with the bugs - but something about this just doesn't feel right.
Rationally, as a software guy, this seems somehow unfair. After all, even as it was launched and without any further changes, ST2 is a good product at a low price.
But the reality is that I feel the same way as radiac. When I chose to spend real money on a text editor -- not exactly a field where the free competition is lacking -- I did so because I wanted to support and encourage a project that did seem to have a lot of nice little touches and did seem to keep coming out with them. The obvious and abrupt end of the stream of incremental updates the moment ST2 went final does irritate me.
Unfortunately, contrary to the post I just read about how stable ST2 is, I have seen irritating crashes that stopped me using it for some work, and I haven't seen a bug fix even for that, nor any other improvement since I sent the money. I probably won't pay for ST3 at this point, because at least now I've figured out what does crash ST2 and how to avoid it, and fairly or otherwise, the assumption in the back of my mind is going to be that ST3 might make a few minor improvements of the kind we used to get anyway, but if it has any sort of crash or data loss bugs they won't get fixed.
As a prospective user of Sublime Text (3, now), it's interesting to think about how I would feel had I bought ST2 a year ago, and now felt compelled to upgrade. The price is semi-negligible, in terms of how much one pays for a quality tool -- it's a fraction of the price of Komodo IDE or PyCharm, for example -- but the hassle is still annoying.
As Silhouette points out, it really makes one wonder about how long "support" (bugfixes, etc) will last for the current version. I think one of the more interesting questions to arise from this thread has been what the difference is (or should be?) between a point release (vN.5) and version N+1.
[1] http://semver.org/
That's what I view as honest, "I'm going to work on ST3 to convince you that its worth buying."
I haven't faced the same quality issues you speak of. TM2 has been rock solid for me. The only thing that never felt right was the theme (install Soda) and icon (Yuck, reminds me of Comic Sans)
As both a user and a developer, I don't think it's unreasonable to expect paid software to get support and bugfixes for a while - at least until the next version leaves beta. "Pay an extra 50% and maybe I'll fix the bugs" doesn't seem fair.
[Not that I'm saying this upgrade isn't worth it]
I don't get these price discussions. If you earn your money by programming, I think it is crazy to be cheap on your tools if you can get the job better done using them.
If you program occasionally, then use some free open source editor.
People on construction sites don't use the cheapest tools available for a reason. If you use it to earn money, you shouldn't be short sighted.
If you tell me a Ford Taurus costs $40,000, justifying that by telling you I spent $100,000 on a broken bike doesn't make the former a good deal.
The way I see it, $70 on its own is meaningless. A lot of people are taken aback because it feels like $70 for an advanced text editor. And in many ways, it is that with some IDE flair built-in.
I own a license and honestly still find myself in Notepad++ for a bunch of things. As a professional programmer, I have come to the conclusion that for my purposes it's overpriced. Your mileage ... well, it should vary.
My point is you can't quantify the value or justify the cost in this way. Surely, a $40,000 Ford Taurus provides more value than the $100,000 broken bike, but that doesn't mean the Ford Taurus is priced appropriately for needs.
I'll happily pay for the upgrade if it keeps the author cranking away at a similar pace.
Absolutely.
>Goto to symbol is great, but all other bullet points taste like what I expected 2 to have once it left beta (basically, speed and not letting plugins crash my session).
I bought ST2 without expecting all these features. Taking the effort to add out-of-process plugins? That's more that the TextMate guy has done in all 6 years of dabbling with 2.
On top of that, it has other nice stuff I want. It might be OK calling it 2.5, but it's not a scam by any imaginable stretch of the word.
>Isn't this a clever way to make users buy into a paid upgrade for a stable version of an editor they already bought?
No. Did you find ST2 any less stable than any other editor out there? I use it for a year for working on 3-4 different languages and it never has crashed on me.
So, I appreciate the cynicism but it's misguided here.
This is a discussion about sublime, not other editors. And if other editors have shortcomings, it's not an excuse.
I also think that after paying for software the least you can expect is relatively bug-free code or quick updates to fix them, and a reduced number of crashes. That is, for software that has left beta to be labelled stable.
Yes, but only if by "spreading shit on everyone else" you mean:
1) a comparison between the speed of development/releases of ST (which was the very topic of this comment thread) and that of TextMate.
2) a generic statement that ST2 was as stable as any other competing browser.
So, really NO, not at all. Oversensitive much? As if "the other editors" (of which I only mention _one_) are gonna feel hurt?
>This is a discussion about sublime, not other editors.
No discussion about anything can be made without relating to other things, especially of it's own category.
If someone tells you "is this editor worth it" the only possible answer will take into account the other editors and what they offer.
this, and the rest of API-specific features will add 0.5 to make it completely "worth" the 3.0 tag.
I've seen how GDB works, and debugging this way seems much less productive. You don't see your whole source code, and you don't constantly see the values of watched or local variables, etc... Is there a different debugger you use for this task when developing using only a text editor (vim/emacs/sublime)?
I'd ask the reverse of you. Why do you spend time in a debugger at all? For 99% of the bugs logical thinking and a few printfs work faster and better ran blindly running around setting breakpoints and examining values.
Though learning how to use the debugger is a good skill to learn, these days I don't know anyone around me who has ever used a debugger, or even finds a use for it. I think the best tools of our age are really REPL's, which allows you to test out your guesses/hypothesis in the form of snippets.
Personally I have probably used a debugger 5-6 times in my whole programming career, these days I hardly find a use for it.
On the other hand, I find tools like these very useful: https://metacpan.org/module/Devel::NYTProf
Memory stomp bugs. Race conditions.
And some Entrprise OO problems - inspecting 260 layer stacktrace and exploring very complicated structures.
I agree that printf works better than "blindly running around setting breakpoints", but so does pounding a 12-pack of beer and then hitting yourself in the face with a mallet until the solution comes to you.
On the other hand, learning to use a modern, advanced debugger and then applying that skill along with some of that logical thinking can be extremely effective in finding the cause of bugs as quickly as possible.
For languages like Objective-C or Java, I think the 'real men don't need a debugger bro' attitude is nuts. It is different for a lot of newer and/or more dynamic programming languages, which simply don't have debuggers anywhere close to as powerful as those of IntelliJ or Xcode/lldb.
Also I hate writing prints over and over. Sometimes it is imply faster to put a breakpoint, look at the value and then pop it away. As opposed to manually writing the print, then check, and then removing it.
Thats just my opinion though.
Once you learn how to use a debugger properly it is infinitely better than printfs.
I've been programming professionally for nearly 20 years, in languages ranging from Perl to C/C++ to Javascript, and the only times I've used GDB in the last 15 years have been when C/C++ code is segfaulting and I want a stack trace. The rest of the time I use print/printf statements. I've built some pretty successful software this way, some of which you've probably heard of or used.
On the other hand if I were coding exclusively in C/C++, or Java, or using an IDE for my work, I might use a debugger more.
I'm getting up there too. And I know lots of older programmers with very bad habits. Many who have also working on household names. Age+popularity != skill/quality.
Doing that in anything but interpreted and micro applications seems like a massive waste of time and effort(both placing the printfs, recompiling, removing them recompiling.
We've all done it. It doesn't mean its a good way to do it.
And like I said above it can introduce bugs into your code doing so. I remember one case where a printf for debugging changed the memory in such a way as to make an uninitialized variable work. After testing when the printfs were removed the application would stop working.
Introducing code into your code base with the intention of removing it later when there is an easy way to not do so is asking for trouble.
But honestly, visual debugging is nice and all but I don't know if the debugger is really the biggest loss of not using an IDE - for me it's more the code completion, navigation and refactoring support I'm after. You can get most of that going pretty well with Vim but it's a bit of a hassle.
Firing up GDB for those rare segfaults which I don't immediately know the cause of (the last 2 lines I wrote, usually) gives me a stack trace very quickly, and lets me dump the values of the variables in that frame. I rarely need more. That wasn't the case back in my enterprise days.
GDB is very powerful, check out its integration with emacs for example (not something I've used).
I'm also Vim user who has considered jumping to Sublime several times, but never quite managed to achieve escape velocity. (Though I hadn't realised until now that the Vintage package is an open repository)
Some random things off the top of my head:
* No block cursor (the block cursor plugin doesn't really work)
* When you switch between files, it keeps jumping back to insert mode, but you don't immediately notice (especially since there is no block cursor). There's a setting, but I've never been able to make it work.
* Autocomplete and the dot command don't work together
* Macros are flakey
* Visual mode and the dot command don't work well together
Otherwise, here's the issue page: https://github.com/sublimehq/Vintage/issues?state=open
About 25% of those issues annoy me personally. There are a lot of commands that leave the cursor one off, which messes with my muscle memory.
As far as a vim-style editing plugin goes, vintage has by far been the best I've encountered. It's one of the few where it's fairly straightforward to add in the hacky things I've done to vim and still get a similar experience.
The problem is that if you want all the fixes you pretty much have to compile a version with all the pull requests yourself as they don't get merged into mainline in a timely fashion. I would personally be much more keen to fix these things if I knew that my efforts along with everyone else's were expediently dealt with.
I do have vintage_start_in_command_mode set, but that apparently only works on startup (I read somewhere on the forums that it's a per-file setting, whatever that means).
Vintage is pretty good, but I don't agree that it is top shelf - ViEmu and jVi are both better Vim emulators IMO, and Vrapper and XVim are better in at least some regards.
* Set `"vintage_start_in_command_mode": false` in the vintage preferences.
* You can remove the autocomplete on '.', just look through whatever plugins settings or bindings.
Also, make sure you get the plugin VintageEx.
http://www.sublimetext.com/forum/viewtopic.php?f=2&t=107...