Sublime Text 3 builds picking up steam again | Hacker News Reader

Sublime Text 3 builds picking up steam again

sublimetext.com

120 pointscoldtea105 comments

I'm a co-owner of a small software business, so in a very similar situation to the Sublime Text developer (with the exception that my product is much less successful). I went and looked at the linked-to list of builds. There's a bit of a gap from December 2013 to May 2014. But then there's a release every couple of months.

I know that in the past the builds have been fast and furious, but, honestly, I don't see any reason to have a new build more than every couple of months. More than that and it wastes my time; I suspect the ST developer has learned that more frequent builds waste his time as well.

Sublime Text is fast, powerful, intuitive, and--the killer feature for me--cross-platform. It's well worth the money to me now, regardless of its long-term future (in the long run, we're all dead). While development has been sporadic, at least it seems like the developer has not succumbed to the Moby Dick/Second System effect, so that's a plus. It would be great in the long run (i.e., when the developer tires of full-time work) if it were open source, but it's nigh-impossible to support oneself with open source applications, so it seems healthier now for it to be a proprietary app.

The problem with Sublime in 2014 was not the number of releases but the fact that the developer more or less just disappeared for a year.

I am totally fine if he does not release something new for half a year, but at least he could've written a short blog post that he will take some time off. Even a short "Hey guys, I am still working on it but things are very slow right now" every 8 weeks would've been totally fine.

>I am totally fine if he does not release something new for half a year, but at least he could've written a short blog post that he will take some time off.

He did write a short post of that effect.

>Even a short "Hey guys, I am still working on it but things are very slow right now" every 8 weeks would've been totally fine.

The TextMate guy posted frequent updates just like that -- and it got nowhere.

But the thing is with Sublime, these months-and-months-long gaps in the release cycle yield incredibly modest improvements.

The 8+ months between 3059 (2013-12-17) and 3065 (2014-08-29) yielded 1 significant (but Windows-only) feature, 8 very minor new features, and 4 bug fixes (including crash bugs).[1]

That's so much less than, say, Bare Bones does in an equivalent time frame with BBEdit[2], that it is laughable.

And, significantly, it is also much (much!) less than Textmate 2 does currently[3].

I think Sublime Text had its Textmate moment[4] sometime around ST2, and it shows. The dev gets rich[5] (congrats) and then — sure! — doesn't feel like working on a text editor for a few weeks, which become months and years.

Textmate solved that by going legit open source. It is hard to think that Sublime Text will be able to solve it without following suit. (But I suppose it's also possible that a year of waning sales might re-light the fire.)

Disclaimer[6]: I have paid for and still use Sublime Text, Textmate, and BBEdit, in addition to many other fine and not-so-fine text editing products.

[1]: http://www.sublimetext.com/3

[2]: http://www.barebones.com/support/bbedit/archived_notes.html

[3]: https://github.com/textmate/textmate/blob/master/Application...

[4]: http://blog.macromates.com/2006/year-in-review/

[5]: for values of rich approximating 'can buy a $1,000,000 house with cash, but still can't afford a private jet'

[6]: in the modern usage meaning 'tangential statement about my background that is not actually a disclaimer'

>That's so much less than, say, Bare Bones does in an equivalent time frame with BBEdit[2], that it is laughable.

And yet, BBEdit is nowhere near as capable a programming editor as ST2/3 + plugins is.

>And, significantly, it is also much (much!) less than Textmate 2 does currently[3]

And yet, Textmate 2 is an immature software that doesn't improve much upon Textmate even.

Your comment makes me think you aren't very familiar with BBEdit, or how capable it is.

I personally don't use it for programming, but I do use it for certain text processing tasks; dealing with malformed international text encodings, converting bank CSV downloads to sane UTF-8 and stripping bullshit, editing HTML, and certain other one-off tasks that it's especially well suited to.

Even so, however, more shipping code has been written in BBEdit than will likely ever be written in Sublime Text, unless Jon Skinner gets back to work and stays extremely focused until 2035.

As for Textmate, I certainly haven't been a fan of it historically[1], but it gradually and grudgingly won me over in 2014. I don't tend to attach myself to editors, but I just found myself reaching for TM2 more, and ST3 less, over the course of the year. Frequent improvements are good, but fast resolution to bugs is perhaps even better.

And I personally think it has tremendous advantages over Textmate 1.x, not the least of which is being able to edit the text I need to edit [1 also].

[1]: http://masonmark.com/mother-fuck-textmate-to-hell/

>I personally don't use it for programming, but I do use it for certain text processing tasks; dealing with malformed international text encodings, converting bank CSV downloads to sane UTF-8 and stripping bullshit, editing HTML, and certain other one-off tasks that it's especially well suited to.

I've used BBEdit (and TextWrangler) for lots of years. For those kind of tasks it's fine (and better than ST).

It's not a good programming editor though.

>Even so, however, more shipping code has been written in BBEdit than will likely ever be written in Sublime Text, unless Jon Skinner gets back to work and stays extremely focused until 2035.

That's just because BBEdit was out there longer. More shipping code has been written on some horrible Windows editors too, but that doesn't make them good.

Given the discussion here, it seems there's a clear need for a text-editor that's cross-platform, fast (like ST, unlike Atom), open-source (like Atom, unlike ST), very configurable (like Atom and ST), easily extensible (like Atom) and easy to use/grasp for an user accustomed to typical windows applications (like Atom and ST, unlike vim and emacs).

Seems to be something like this could be done using QScintilla. Qt would give it an excellent cross-platform support, Scintilla a good editor with a speed of C++, and the ease of development and extensibility would be possible thanks to either PyQt (Python) or QtQuick (JavaScript). Just a thought...

My feeling is that your point about vim and emacs applies more to vim than emacs. The caveat here is that I had ~15 years of vi/vim usage going on before switching to emacs ~5 years ago. I can plainly see where modal editing is foreign to new users from the start. However, I'm not sure emacs, which ships with "normal" keyboard shortcuts by default in most packagings, is the same. Emacs has a relatively smooth path from, "I'm going to use this like Notepad++" to "Emacs is my god / lover / email client now."

At least that's my impression, and perhaps the warped impression of someone incapable of recognizing weirdness.

It's great. SB3 beta has been completely stable for me the past year, so looking forward to testing the new builds.

The plugin system dies for me regularly. I wish I didn't have to quit ST3 to fix that.

That sounds like a bum package, or a corrupted install. If you are using Package Control you can copy the Packages/User/ folder to a fresh install and install Package Control to try fixing it. PC will do a fresh reinstall of missing packages.

I'd venture to guess that the grandparent poster is on Windows. On Windows, after resuming from sleeping, it's known that sometimes the plugin_host.exe will crash.

I use like 15 plugins. None has died on me (OS X).

What exactly dies on you? I use the Linter (and several plugins for that), AutoPEP, GoSublime, etc.

I'll check next time.

I have never had that issue, but I also only use a few plugins (Emmet, Blade Highlighter, SFTP, Gist etc.).

Too late for me. Atom replaces sublime in my workflow.

Same for me at the moment. I've heard a lot of complaints that it cannot open large files and it can be sluggish; I don't regularly need to open large files (I'd rather process large log files from a terminal for instance) and the performance is fine for me. I like that Atom is open source, plugins are written in JavaScript and the rate at which new plugins are coming out is impressive.

I tried Atom for a week. The little half-second delays start to bite after a few days, and after a week you want to throw your computer out the window.

Think about it. It's 2015. My PC has 8 cores running at unimaginable speeds. It has 16 GB of memory. And my text editor couldn't open files over 2097152 bytes.

Am I living on a different planet from everyone else? How can people accept this as a normal situation?

I agree completely with this. In my job, I need to open up a lot of CSV files ranging from several MB to hundreds.

Sublime Text, whilst not perfect is far better than anything else out there. It doesn't struggle with these files either.

vim would open multi-hundred megabyte files in seconds, if only you can invest in learning its modal editing mechanism (which, to be fair, is fairly arcane, and is proven to be a worse UI than free form editing).

Proven? Where?

whilst not perfect is far better than anything else out there. It doesn't struggle with these files either

Except on Windows it does struggle, a lot, and others like Notepad++ open large files way faster.

Just checked it again: a 20MB matlab m-file opens instantly in NPP however it takes ST3 about half a minute. Half a minute, seriously? After renaming it to txt to get rid of syntax parsing it takes like a second. Which is still longer than NPP and starts to get seriously annoying with files of hundreds of MB.

Still, it's my go-to editor.

Your remark about modern computers being really fast and software still managing to be slow doesn't just apply to Atom, really lots of software is frustrating in that way. Maybe that's why people accept this as normal: because sadly it is. Try opening an "Open file" dialog on basically any modern desktop...

More and more I tend to use software that is either minimalistic or started in another era (Emacs + command line tools). The one exception is the web browser which has to be modern or a bunch of websites won't work.

No, it isn't acceptable. That's why I use tools like vi/m, ed, and sam to open gigabyte sized files. On my intel dual core laptop with 3GB of RAM (yes 3GB, it is weird).

3GB... 4GB - 1GB carved off for shared memory graphics?

If he has got 4Gb of RAM it's more likely he's using a 32bit OS that can't address the extra memory.

I'm a Dynamics AX developer. Our environment takes minutes to compare text files. I would love to have your "half-second" delays :)

I agree the 2MB limit is weird but, like I said, it rarely impacts me. I use Atom for coding and don't think 2MB source code files should be a normal situation.

I don't notice any half second delays though. I used to be an Eclipse user and recall it being much more sluggish.

Just tried opening a file larger than 2MB....nope. End of Atom tryout.

Its like they didn't even read it? http://www.finseth.com/craft/

(I'm kidding, I understand the slowness is due to the webkit rendering...)

I'm using Atom to code. If you have a source file bigger than 2mb, trust me, the Atom limit is the last of your problems. :)

I have to open CSV files all the time that can easily be hundreds of MB. I'm not doing anything wrong, it's a dataset.

I see no need to switch to Atom since Sublime is faster, has a more established plugin base, and can open large files. Sublime ain't broke, so why fix it?

One thing that blows me away about Sublime is its grep performance on Windows. I am an emacs user but use Sublime on Windows since I havent been able to find a way to make emacs match the speed of a recursive grep search on Windows.

Another place where Sublime text is noticeably faster is in syntax highlighting large files.

Interesting, do you grep for e.g. finding symbol references? i.e. doesn't emacs have a feature of finding symbols semantically?

Often I am working with files that are not code.

I've used ST in the past, but due to slow release cycle, I switched to Vim. What really bugs me in ST is the fact that the guy doesn't have time to work, but still, it's not open source for the community to work together to achieve a decent release cycle.

ST in its current form is better than most other editors, so why would it need a faster release cycle?

The Plugin System could do with some polish, for example. Whenever one of my plugins broke it was a complete mess to remove the bad file.

Are you using Windows? That sounds like a Windows filesystem locking issue. It is a constant pain in my side and the source of lots of extra code in Package Control.

This.

It is not that the editor is in bad shape. The periods of of inactivity made me feel like the editor could be abandoned or discontinued. I went back to Emacs.

How inactivity affected it's performace? It was same. Did you started encountering many bugs? Or badly looking for some feature?

It seems to me that ST would really benefit from being open-sourced, but I guess it depends on how much cash he's getting out of it, and whether he can afford to give that up.

I stick with ST because the plugin ecosystem is vibrant, it's hackable in a language I'd actually want to write, there's as much time-saving juice as Vim without me having to learn non-standard keyboard commands for the very basics (sorry, I like my arrow keys and Ctrl+x/c/v, and - god help me - my mouse), and it's not a sluggish, half-complete rip off of itself (cough Atom). I know enough Vim to get around a log or config file, but for serious work, Sublime and my brain are partners for life. (Unless Atom improves dramatically, anyway.)

I don't suffer from the slow development cycle, but I'm sure others do, depending on what it is they need.

Yeah it's great for me because the development cycle doesn't really faze me. I'm not really itching for anything new or for any bugs to be fixed. And if I do itch for something new, odds are there's a plugin for it.

You can use arrow keys, Ctrl/Cmd+x/c/v, and your mouse in gvim and macvim just like any other editor.

> due to slow release cycle, I switched to

I've read this argument multiple times and I just don't get it. Is it because you were waiting for a feature that hasn't been implemented? What's a decent release cycle? How does a indecent release cycle affect your daily usage of the text editor?

My thinking is that some editors tend to be fashionable. I don't mean that negatively, just that their mindshare is transient until proven otherwise. They have a subset of users that are not massively invested in the platform, and will move to something that looks more interesting or more secure/active/etc.

If that subset is large enough such a migration can harm the ecosystem: less users, less developer mindshare in bugfixing or plugin development and so on. It can then work like a run on the banks where people get out before the problem gets worse, making the problem worse.

Interestingly, vim is often one of those editors: when TextMate was originally dying (pre open-sourcing) there seemed to be a new "why I'm switching to vim" or "how to set up rails dev in vim" post every day. I'd wager that a lot of people moved to vim as a result, then bounced off again.

Because there are many annoying small bugs that prevent the editor from being completely useful.

Like what? Haven't found any in the 2+ years I'm using it for Python, PHP, JS and Go.

Sublime Text last released on July 8 2013; Vim's last release was on August 10 2013. So.... I guess I can see your point?

As for open sourcing it: if you have barely enough time to work on a codebase yourself, it seems unlikely that becoming the co-ordinator of an open source project is a reduction in the amount of effort you have to make. And poorly-run open source projects don't generally have a fast release cycle.

>I've used ST in the past, but due to slow release cycle, I switched to Vim.

You do know that there can be like decades between major Vim releases, right?

I've been a long time ST user, but when I out of curiosity started playing with Vim and slowly get used to it, I now prefer it over ST most of the time. But I'm glad that Sublime Text is alive again.

Same experience for me. I started using vim about one year ago, and I have been very happy with it. Having to take my fingers off the keyboard to move around a document or highlight things-- it's just unthinkable now. But I'm glad sublime is there, cross platform and easy to use, just in case I'm on some foreign machine and I don't have time to set up my vimrc and vim plugins. I also recommend Sublime to people who are just starting on programming in a language like Ruby or Javascript as it works just like Word out of the box.

I get `unable to apply patch` from the builtin updater. Happened for 3067 last week too. Some kind of permissions problem? I've never installed it in any kind of unusual way...

Are you on Windows? I did see a post about elevated privileges here: http://www.sublimetext.com/forum/viewtopic.php?f=2&t=17470&p...

On OSX 10.9.5

You may want to leave a reply on the Dev build post for Jon to look at then.

Meh, I'm trying to just switch over to emacs, so far its been a blast, even with implementations of AC, speedbar,yasnippit, and other packages,i dont feel that ST is going to cut it for me anymore.... ill keep it installed still its a very beautiful application. :)

I'm starting to get called neckbeard at work for being a emacs advocate..... :\

As someone who finally shelled out the money for it and a few paid plugins, I'm really glad to hear this!

Which paid Sublime plugins do you use? It's always great to discover useful new tools, and seeing others pay money for them is a strong endorsement of utility!

+1 I'd like to know what plugins people have found worth paying for.

Most notably for myself: Sublime SFTP, SublimeGit, and Sublimerge.

I'd pay for Anaconda or SublimeLinter beyond donations in a heartbeat if it did have a paid option, as well.

http://wbond.net/sublime_packages/sftp https://sublimegit.net/ http://www.sublimerge.com/

http://damnwidget.github.io/anaconda/ http://www.sublimelinter.com/en/latest/

BTW nobody mentioned Limetext, which attempts to implement a SublimeText clone in golang (and other features like a terminal frontend).

http://limetext.org/

Picked up, but no match with Atom. I'm disappointed as I've invested over $200 in its ecosystem (including a paid license for it).

I don't really see much point in Sublime Text now that GitHub's Atom is a pretty much a one->one replica but free, open-source and has a rather nice package manager for plugins.

Well, Sublime Text is much fast er.

Absolutely. My one and only complaint with Atom is that it eats up so much CPU. Just typing sends my usage over 50% :(

There is a point (mainly inertia and speed), but there won't be one for much longer. ST3 is a really great text editor, but it is only being developed by a single programmer.

Adding more mothers to the production of one baby isn't necessarily going to speed up the process... I suspect that creating a text editor is not an embarrassingly parallel problem.

Yawn. Of course a small team will be able to ship this thing faster and with more features. If you add 20 more people that probably won't help, but 3 or 5 should.

Strangely, I believe two other programmers work on it.. or something, but can't actually work on it until ST3 has shipped (ST3 is still in beta). I don't have much faith in future updates.

I think it's just Jon now. I believe there was another developer at some point.

A text editor is made great by the plugins it has, I see no reason why a sufficiently dedicated crowd of people could'nt create better plugins in Python. The main developer has only to concentrate on a fast and easy to use text editing API so to speak.

The ST3 API is actually quite terrible. Superficially, it looks OK, but in truth it is:

1. extremely buggy (its trivial to crash ST3). 2. extremely limited (basically 3 pre-made widgets) 3. subject to buggy third party software for distribution (package manager often ships broken/buggy code).

Of course, one can work around the bugs with sufficient time by figuring out the magic order in which API calls can be made, or by dumping them into setTimeouts. In the mean time, Atom is building a modern, extensible editor on top of two other extremely popular platforms.

I'd appreciate it if you could take the time to report issues that you find with Package Control - I looked and couldn't find a single bug report from you. I guess sometimes it is easier to complain on HN than submit bug reports.

BTW, all of the issues you have with Floobits on Sublime are trivial to work around (in fact PC 3.0 fixes them all for you). But from your comments here it sounds like you dislike Sublime so you'd rather just make excuses.

Yes, we should report up stream. I apologize for speaking ill of Package Control- it has been quite stable lately.

The problems with ST3 don't make it impossible to develop plugins, they just make it harder than it should be. Bugs in the API and the 2/3 split have wasted weeks of our time.

Atom was very slow and cumbersome for me, nowhere near as polished as Sublime Text.

Atom is far too slow, and eats battery life. This is because of the technical decision to render text in a web view.

The slowness is not a solvable problem. Therefore Atom will fail.

On a more positive note, I am so happy to see SublimeText re-activated. The previous builds worked fine for me, but it's always good to see progress.

I see this argument over and over but I've never heard why it's too slow. I enter a key, the text is immediately updated. Sure, starting the editor takes 3 seconds but that's about it. Not only that, but Atom gets a faster startup with every update. The only thing I found bothersome was the 2 MB filesize restriction.

> I've never heard why it's too slow.

Because it uses Webkit and Javascript rather than being implemented natively.

I didn't mean technical reasons but what works slowly. Like: I enter a key and the letter shows up with perceivable delay (which in my experience, even with 100.000 lines isn't the case).

One thing I found extremely slow for instance was copy and pasting of large chunks of text, but that's something I only experienced while testing Atom's performance. For my common text manipulation, I've never experienced the slowness that keeps so many from using Atom. I understand that people are bothered by this, but saying "Atom is slow" imho makes Atom appear as this giant unsuably sluggish piece of software that it is not.

- Text editors have been around for a very long time.

- Text editors are not that complex (even with plugin systems they are not doing HPC work).

- Text editors were not perceived as slow many years ago.

- Our computers have only got faster (10000x range).

- It is 2015 and a text editor is slow (sub-second delays in GUI, large file limits, etc).

- There are text editors not written in JS/Webkit that are not slow by orders of magnitude.

While I'm not bothered by Atom being slowish, I think there is some basis for dissatisfaction here. Of course, nobody is obligated to use Atom.

My point was that Atom is not slow 99% of the time, when doing standard text manipulation. I never argued that there's no basis for dissatisfaction but that the argument "Atom is slow" is often tossed around like some ultimate argument. Often without calling out what is slow (I even pointed out some of Atom's slower operations).

I use Atom over Sublime Text these days but there's no denying that it's much slower. It'll improve as time goes on but it takes longer to start and can very sluggish when a lot of text is being displayed. I also frequently hit the 2MB limit, far more than I thought I would do.

How can it "improve as time goes on"? The developers chose a technology stack that suited them the developers, but which didn't suit the end users of the software.

This happens sometimes when developers make business decisions.

Any improvements will be in the 20%-30% range. Meanwhile, Sublime Text is 10-100 times faster. Atom is dead, in the long term.

That's ill-informed.

1. Atom is an open-source developer tool. 'Business decisions' (whatever they are) should take a back seat to 'developer decisions'.

2. The technology stack is not a long-term constraint on performance. It's perfectly feasible that performance will increase substantially over time.

3. Sublime text is not '10-100' times faster.

I'm a massive Sublime fan, and won't be using Atom. But you're spreading FUD.

User experience should definitely be more important than the technology stack. Also, the technology stack is a constraint on performance now, and now is what is important.

Atom is also huge - 77 MB installer on Windows, while Sublime Text 3 is 8 MB. It hardly fits the bill for a lean-mean-editor.

Atom doesn't have a 64-bit version either. I tried it as a replacement for Sublime Text 3 but it just doesn't cut it. I am wondering why ST3 development had slowed down in the first place.

>Atom doesn't have a 64-bit version either

Hmm?

/usr/share/atom/atom: ELF 64-bit LSB executable, x86-64

edit: its here: https://github.com/atom/atom/releases/download/v0.177.0/atom...

Oh yeah, well not on Windows.

One thing I've noticed about Atom's sluggishness is that it's slow even to scroll. I've never understood this, as scrolling on Safari/Chrome (or most other windows on my computer) is usually buttery. Scrolling in Atom feels janky though.

It seems to be mostly an Atom problem.

Brackets and Lighttable built on same technology are way faster.

Brackets also feels slow compared to ST. Switching tabs has a visible delay (up to 1s) for me.

ST is faster and if you want the fastest it is probably slickedit. However, just pointing out Atom could be better than what it is. Multi cursor editing in Atom absolutely can crawl. In brackets it is much more usuable.

Everyone says it is DOM rendering that makes these editors slow. Since Reactjs just announced native support for android and ios, I'm wondering if this can be applied to the desktop for much better desktop app performance.

I had to ditch Sublime at work because it doesn't properly save files in to my Vagrant. Sometimes there's minutes long delays, used to drive me crazy. Something about atomic save, but whatever setting I try the problem remains.

So now I use Atom a work but I find it harder to customise according to my liking. It also cancels shut down of my machine every single time.

Atom has a 2 Mb file size limitation. Ridiculous.

I don't really like Atom because of the webkit usage, but I strongly agree that using a closed source text editor is a terrible idea for a programmer... when that editor stops being maintained all the time investment learning all it's time saving tricks is lost.

Luckily I've been burned really early in my programming career by TextMate to know better: all my tools must be OSS and cross-platform.

That is a great point. A year without a single beta build, and yet they have not explained to the consumers anything.

Just resumed, as if nothing has happened. That is a warning: you are at mercy of a small & private company, which does not seem to care much.

I don't understand this line of thinking.

For me a closed-source text editor such as Sublime Text makes me much more productive than it's open-source equivelent. The accumulated productivity gains far outweigh the timecost to learn a new tool, if Sublime Text disappeared (a couple of days at most?).

Well, in some time you will lose all your productivity when you have to switch. With a proprietary tool it's not a matter of 'if' but 'when' (unless it's provided by a huge corporation, but then they try to lock you in their ecosystem).

OTOH I will be able to use vim (or a fork of it) 20-30 years from now and become more and more productive with it during the timeframe.

And I don't understand your line of thinking.

You should be using vim or emacs if the "accumulated productivity gains far outweigh the timecost to learn a new tool".

Atom ist not free as in freedom, just free as in beer.

https://atom.io/faq says it's MIT licensed. So, free as in freedom.

The core was close-sourced initially but it's open-source now, they did this a long time ago though.

Reply on news.ycombinator.com