Hacker News Reader

Comment by guessmyname | Hacker News Reader

> With these latest changes, Sublime Text 3 is almost

> ready to graduate out of beta, and into a 3.0 version.

Wow, Finally! I have been using ST3 for several years (wow, years) and always wondered what is keeping the developer from labeling that version as stable. From all the issues reported here [1] I have never encountered one while using the editor for pretty much all my work. Those $70 are definitely worth every penny. Sometimes I cringe from videos featuring ST while using a non-registered license, this week it happened with a course from Google engineers via Udacity, Google engineers!!! As if they don't have miserable $70 to buy a license, I assumed they were in a rush and didn't have time to set the license which I hope they bought.

Anyway, thanks for all the hard work Jon, and recently Will.

[1] https://github.com/SublimeTextIssues/Core/issues

View on HN

> Those $70 are definitely worth every penny.

Same here, buying an ST license is probably the single best SW-related purchase that I've ever done. ST3 works so flawlessly, it's just ironic that it's still technically a beta version. It is actually much less buggy than many "final version" competitors ;-)

On a side note, it is notable how, despite being a closed-source program, ST was able to generate a large ecosystem of open-source plugins; that is not something that happens every day (Jeskola Buzz comes to mind as a similar case: also closed source and with a large open-source plugins ecosystem, but I'm not sure how many people on HN are familiar with tracker-style music software, LOL).

ST bootstrapped its ecosystem by directly and shamelessly cloning every one of its original features from the TextMate editor, and just copy/pasting its entire ecosystem, without contributing anything back. For years there was no special support for actually working on custom features from within Sublime Text, so if you wanted to create new language grammars or syntax highlighting modes etc. you needed to do it from within TextMate. Sublime users would come to the TextMate IRC channel to complain about particular language bundle features that were buggy in the not-quite-compatible environment of ST, and ask TM users to fix it for them. Kind of comical really.

Even still, TextMate is a substantially more carefully designed tool. My impression is that the Sublime programmer didn’t really understand the underlying philosophy behind many of the features he cloned, and kind of screwed up a bunch of the subtler details. (This isn’t really surprising; I’d say it pretty much always happens when anyone just copies something that exists; they seldom perfectly understand the context or ideas of the original creator, so the copy is always at least a bit degraded/distorted, with less clarity of vision.)

Sublime does have the advantage of working on more platforms though.

Can you give some examples of what those features are?

I tried both TextMate and Sublime Text and find ST to be much better for what I do (web, Python and text editing).

Copying or not, "badly designed" or not, in the end Sublime Text is blazing fast even on a big files, extensible with the help of Package Control and has some native features (like multiple cursors) that make the difference.

I switched to ST2 after about 20 years of VI(m). I happily paid the money to NOT have to deal with 50 different plugins designed to get VIm to, essentially, work like ST, with the side bar and tabs. I switched to Mac as my primary desktop not long after, and looked at TextMate. I WANT to support the Apple "ecosystem" in ways like using a "Mac" text editor, but I still work on Linux (and Windows). Not having cross-platform capability is a deal breaker for me, and ST is just as good as VIm in this regard.

> Even still, TextMate is a substantially more carefully designed tool.

Do people still actually use TextMate? Judging by their website [1], for example the screenshots taken under an ancient version of OS X, I thought it'd been abandoned years ago. The last post on the blog is in October 2014.

[1]: https://macromates.com

[2]: http://blog.macromates.com

Tons of people still use it and it's being very actively developed. Check out the GitHub: https://github.com/textmate/textmate

It's constantly being updated.

> Those $70 are definitely worth every penny.

I've said it before, and I'll say it again – the fact that ST saves buffers no matter what has saved my butt so many times I can't even count. The effort it would've taken to restore the lost data had those buffers not been stored would've costed way more than $70 every time. Even if ST was worse in every possible way than other editors (and it's not,) I'd still pay money for this (and I did.)

I don't know if my license will stop working when ST3 comes out of beta (I think I bought it for ST2, but it was so long ago at this point I don't even know) but if it does I'll happily shell out another $70. ST is one of the few tools I use that never, ever caused me any grief. Not once. It just works, works really well, and does all I need it to do.

Agreed. The ability to paste some data I may or may not need after a couple more hours of debugging, and have that buffer save through a reboot -- without needing to save it to a file -- is something I've come to rely on. I only realized this when I tried Visual Studio Code, and noticed that it wasn't doing the same thing.

This is the reason I stopped using Atom and returned to ST. It's just so practical.

For anyone else who is missing this feature from Atom, try the save-session package.

I see on the package page that all its functionality has been merged into Atom itself.

Ah, right! Now that you mention it I remember following that ticket. I must've neglected to remove the package after that happened.

I noticed that too, but for some reason I can't seem to figure out how exactly it works. It's not just like in ST, as my buffers get lost. After a while I just gave up because I don't actually need to switch from ST...

There's a confusing bug related to this feature. Currently, Atom only automatically re-opens unsaved buffers in "project" windows (those associated with a particular directory). See https://github.com/atom/atom/issues/10474 for details. It's a real bummer and I hope it gets fixed soon.

The fact that it is a pseudo-free piece of software is one of the biggest reasons for its success (apart from its blazing speed and the rugged, minimalist engineering aesthetic). People just get used to the occasional nag screen as a sort of background noise.

I'm hopelessly tied to IntelliJ's amazing IDEs for any sort of programming, but Sublime is my EDIT.COM for all other writing, especially note-keeping. I used it in that capacity for around a year, guiltily enduring the nag-screen, before I got around to buying it. This free-but-nag approach (not Nagware - too negative) was unusual for the times, but it reminded me of the Shareware days when successful software like PKZip spread virally, but extracted commercial value only when the users felt like it.

The fact that it is a pseudo-free piece of software is one of the biggest reasons for its success

I think the demise (in terms of active development) of TextMate should not be understated as a factor in ST's success. At the time Sublime Text 2 came out, a lot of TextMate users were frustrated with the lack of progress on TextMate and hopped on the ST bandwagon.

Ironically, ST had the same fate for a while. But it's good to see that there is some movement again.

I have a license too but as I'm moving between workstations and sometimes between accounts even on the same machine, I don't always paste the license in, because it would be extra effort to dig it up and copy-paste it...

I bought it on day one when I discovered that Sublime supports Windows, Linux & Mac.

I wanted a "modern editor" after vim, which works the same way across platforms, easy to install and configure, supports proportional fonts and does save on focus lost, yet still neither a memory hog nor a snail.

I never would have paid just for getting rid of the nag screen, but I was so impressed with its quality, I just had to express my gratitude by paying. :)

It's probably not that they don't have $70, but that they don't have time and it's easier not to bother. Buying software at big companies can be a pain.

Ok, let's rephrase: anybody with a Google salary can afford Sublime Text.

Also, when Sublime Text has a reasonable amount of popularity within Google, they could just purchase a site license for N users.

Must be a simple mistake. You can definitely get a ST license at Google if you want to.

I know that I often put off inputting my license on a fresh install because it's kind of a pain to hunt down. Or at least it's easier to dismiss the occasional notification than it is to log into my email and try to find the license key.

100% agreed, worth every penny.

Sorry, I must disagree. For 70 bucks you get developers who hardly fix bugs, who don't listen to users (I posted a few feature requests in their site and was banned) and with a crazy architecture (try and change the highlight colour of brackets in BracketHighlighter and see what I mean). They are worse than Microsoft. Screw them.

It was great when it came out, but now Atom is better.

I share your sentiment about the buggy software and the unresponsive devs; I moved to Atom for the same reason.

However great Atom is though, it's unbelievably slow and nearly unusable because of that. Unfortunately, I haven't been able to find a better alternative since.

Are you using the latest version? I can hardly see a speed difference compared to VS Code anymore, even for big projects and files. It's certainly very far from being unusably slow.

>buggy software and the unresponsive devs

I mainly use VS Code for that reason. It does feel a bit more polished and Atom is missing some much requested features, most notably a list of open files in the sidebar (the plugins that offer this are all terrible).

Tried Atom for Mac right now. Opening a tiny (10k rows) csv file took multiple seconds, opening a larger (100k rows) csv put out a warning about potentially taking a lot of time and in a second simply crashed before loading it.

Opening a CSV with 100k rows takes about 10s for me and is pretty workable with an i7 and 16GB RAM. Selecting and editing text is almost instant.

...

And why should you need that kind of machine to do text-editing?

If a text editor can't open a big file unless you are on a beast of a machine, it isn't a very good text editor.

A 5-year old i7 is far from a beast machine. You're a typical Apple customer that pays too much for an underperforming piece of crap and then complains about the performance.

My computer - a 3+ year old i7 - opens the 20 million line CSV from http://files.grouplens.org/datasets/movielens/ml-20m.zip in ST3 in about 25s and opens the 1 million line CSV from there in little over a second. 10s to open a 100 thousand line file on a modern machine is unnecessarily slow.

I didn't say 10 seconds was fast and it isn't, but for the very few times I have to open files with 100k lines it's more than enough and far from unusable.

When you regularly work on such files, Atom is the wrong tool for the job. For regular programming however, I'd argue it's far better than Sublime Text by now.

> However great Atom is though, it's unbelievably slow and nearly unusable because of that. Unfortunately, I haven't been able to find a better alternative since.

Have you given emacs a shot? While once upon a time it was derided as eight megabytes and constantly swapping, it's extremely fast after forty years of Moore's Law.

It's cross-platform: if you run an OS, odds are emacs runs on it. It runs in both the terminal (convenient for remote sessions) and in the X/Cocoa/Windows GUIs.

It has modes for just about every programming language in use, and then some.

It has a plethora of keybindings for dealing with code semantically, e.g. navigation by expressions or blocks. If you prefer, it also has vi keybindings.

It's extraordinarily extensible, so much so that web browsers (three that I can think of), mail readers, news readers, process browsers and shells have been implemented in it.

Indeed, for many people emacs can become more of an OS than their OS.

It's pretty awesome.

As a former Emacs fan, I think Atom is actually the best modern alternative to Emacs.

I just recently looked at my old .emacs file to discover that the majority of code in there was to get the features that come out of the box with Atom. Of course Emacs does allow you to configure and program way more than Atom, but the downside is that you have to do it because the defaults come from computer history museum - it's great fun though if you like to learn about the history of the field.

I've been pleasantly surprised just how easy it is to extend Atom. It invites you to configure it, with very approachable docs and built-in tooling, but it doesn't force you to.

>Sorry, I must disagree. For 70 bucks you get developers who hardly fix bugs

I've been using the beta of ST2 for years and the dev of ST3 for years after that, and have seen hardly ANY bugs. (on OS X). I use with it SublimeLinter (Python, JS, PHP), a Shell linter plugin, GoSublime, JSONFormatter, Vintageous, and a few other plugins.

>who don't listen to users (I posted a few feature requests in their site and was banned)

Maybe it was the tone that got you banned? The forum is chock-full of feature requests. I've posted some and didn't get banned. Whether they are implemented or not depends on the roadmap and their popularity/feasibility. Obviously not all will be.

>and with a crazy architecture (try and change the highlight colour of brackets in BracketHighlighter and see what I mean).

BracketHighlighter is a third party plugin, so nothing to prove some ST3's supposed "crazy architecture".

>It was great when it came out, but now Atom is better.

Atom was, is, and due to its architecture, will always be, slow. It has been slow every time I've tried it, and it's the common complaint of every Atom user whenever Atom is on HN.

> Maybe it was the tone that got you banned? You have no basis for this statement.

> BracketHighlighter is a third party plugin, so nothing to prove some ST3's supposed "crazy architecture". BracketHighlighter is forced to do things in a certain ways by ST3's crazy architectura.

So what are those "certain ways" that show ST3's "crazy architecture"?

https://github.com/facelessuser/BracketHighlighter

And is it crazy overall, or just when it comes to handling brackets from a plugin, in which case, it might just be a corner case that was not originally catered for?

You can't define a colour in the plugin. You HAVE to define it in a theme. It's ridiculous, because then you have to define it for EVERY theme you switch to.

You're free to make a pull request for the plugin to implement this.

It CAN'T be implemented, that's the point

This sounds totally sane -- and the best way and most flexibile way to go about it, not crazy.

Highlight colors should be the responsibility of highlight themes, and users should be able to change them by changing the theme they use or adjusting it to their taste, not by ...hacking into a plugin that hardcodes them.

At best you could argue that the plugin could be allowed to hardcode a color, and themes could optionally override it -- but even that breaks separation of concerns.

Even if it was crazy (which it is not) it's a tiny part of ST (just how the syntax highlighting works), and wouldn't be proof of any general "crazy architecture" of the editor.

Why is hacking into EVERY THEME you wish to use better than hacking into a single plugin?

Reply on news.ycombinator.com