New Sublime Text update (opens in new tab)

My only interaction with Atom so far was trying to paste a 8k chars line in a dojo on someone's recent mac pro. It crashed every single time and crashed again on opening as it was trying to load the file with the long line on startup. In the end I had to use vim to open it, was instant and I could actually remove that line (not a vim user).

Exact reason why I too stick to ST3.

This was a concern of mine before switching from Sublime to Atom on the Atom 1.0 release, but I don't open moderately large files often so I really don't worry about it anymore.

Atom has come a long way and I love using it.

There have been times where files have been too big even for Sublime Text to load on my Macbook without slowing it down. In those cases I've used Vim with the LargeFile plugin.

> Trying to open a 10mb file in atom causes it to chew up 1.2gb of ram

Truly?! That's a factor of 100x, that's ridiculous.

TBH, I'd kind of expect an editor to use a factor maybe 2x of the loaded file (for quick access indices, searching, etc). More if you count undo-buffers, of course.

Do you edit the large files, or only look at them?

That's what I've found. I've been using Atom for a couple of weeks now and have decided to give up on it. I'm using it on a fairly substantial Macbook Pro and the start up lag drives me nuts. Back to ST3 I guess...

Absolutely zero typing lag on Atom here. Wonder what is causing all these different experiences.

Disclaimer: I haven't used any of the 3 extensively, but I do play around in them from time-to-time. The main difference to me is that ST comes as a bare-metal editor with the potential to do just about anything, while Atom and VSC come with some built-in features that just make life easier and the ability to extend it further.

A concrete example would be VSC's git support; out-of-the-box, it's a full-featured git client, and even if you prefer the git cli for most operations like I do, VSC automatically reads the .git directory and then creates a tab that shows your current changelist (modified, staged) with a visual diff of the files. Also allows you to easily do the common stuff like checkout a branch, commit, push, etc.

If you're a big fan of ST, you probably won't like the alternatives unless you have some frustrations with ST, because ST is probably more powerful overall, but compared to Atom & VSC, the learning curve is also quite a bit higher.

The fact that a minor update got released isn't a rare enough occurrence to warrant a highly-voted post on HN.

Snark aside, VSC has grown up quite a lot, very quickly. If you like Sublime, good for you, stick with it. But it looks like VSC is going to pick up support for more new things, faster. Personal favorite: support exists to plug in third-party debuggers and get debug tools/build errors inside VSC.

This may or may not matter to you, but VSCode and Atom are open-source.

That means a lot to me, but I understand that some people won't really care.

They are free and open-source. The latest VSCode has my code to fix CJK word wrapping (and Kinsoku Shori).

VSC has built-in debuggers for node, go, python and c# that work very well.

Atom and VS Code listen to your .gitignore when showing a folder of files. Quick searches ignore those files as well. In Atom those folders/files are still openable (the explorer pane thingy shows them as grayed out).

To get the same functionality in Sublime, AFAIK, you have to create a couple of project files first and add folders into it. Then, if you later make a new folder via the terminal you have to edit your project file to include it.

That's been my biggest headache around Sublime vs. Atom. It's the smallest thing but it's like sand in my shoe.

For me the OSX integration was better for Atom. Little things like the 'Duplicate' option in the project tree drawer. Also better PHP plugins.

Atom is a small bit slower than sublime, but it has just as many or possibly more plugins, has a nicer settings and plugin interface, and is open source and free.

A huge potential, but after trying it a bit I was disapointed by the clunkyness. I'd say it's good for beginners trying to learn html+css.

Ah, I forgot about Brackets. Why isn't it as popular as Atom?

It's sad because it means Sublime dev isn't doing it out of love. Much like Microsoft.

Thought same till I had a look at VS Code.

Yeah Atom still has issues. I've had crashing problems on 4 year old Macs.

But ST makes you pay $70. And also isn't open source. And more people know JS than Python to hack on it. And Github has a powerful marketing team and lots of resources to put behind Atom and it's development. And ST doesn't get updated too often.

One thing that has me switching between editors is Visual Studio Code's multi-file code information feature, or "intellisense". It's especially awesome for types. Another thing is that I find that Atom's syntax highlighting is sometimes better.

ST's plugin API is extremely limited. There's hardly anything a plugin can do to influence the rendering of the text editor. ST plugins can:

* Show autocompletion boxes (e.g. cmd-T)

* Update the status bar

* Edit text

* Tag text regions (which can be used for custom highlighting, e.g. underline errors)

Atom plugins can do almost anything by modifying the editor DOM, but more formally they can:

* Display compilation error messages inline

* Show popups

* Display custom panels (e.g. the neat Git conflict resolver) within the editor window

* Draw custom settings UI

* Extend the file tree sidebar's rendering

* Create and arrange editor windows

* Create custom windows (e.g. Markdown Preview splits the current editor window and shows a live preview on the right-hand side)

etc.

Atom has also been better designed with regard to pluggability. For example, it comes with a single autocomplete system that packages can extend with custom autocompleters. Plugins don't have to invent their own autocompletion system.

The fact that ST's plugins are executed in a sandbox environment also causes (afaik) issues for plugins that want to use toolchains such as Go.

I'd like more customization with the gutter API [1]. You can only have a single icon per line in the gutter, and plugins often fight for that spot.

[1]: https://www.sublimetext.com/docs/3/api_reference.html

plugin system for one.

Well, for one it's not Vim ;)

Definitely at least one other person: http://www.sublimetext.com/blog/articles/sublime-text-3-buil...

And despite their lack of "social media engagement", they do have a Twitter account (@sublimehq) with nearly sixty thousand followers - and they tweet just about as regularly as updates for Sublime Text are released!

Three years ago, Jon Skinner mentioned it was a "3 person company"

Tell that to the Amiga.

A long read, but demonstrates that even amazing products die with crappy advertising: http://arstechnica.com/series/history-of-the-amiga/

Well, until a real competitor like Visual Studio Code comes along, then they do. :)

When moving away from ST2 (too many workspace/plugin issues), I strongly considered Atom. With plugins, I could replicate nearly everything I had spent a couple years setting up in ST2 config and plugins.

But then I landed a contract using vim, and found it has more functionality than both, if you're willing to spend the time. I especially like being able to SSH/Tmux into a session from a tablet remotely and pick up where I left off, even over slow connections.

I didn't write the code in question, but I've done the same thing before. Usually it's because I'm cursoring up and down a file, see some lines I want to comment out, and don't bother moving over to the start of the text first. Syntax highlighting greys out the comment, so it's not visually obtrusive. (Which is another reason I'm baffled that Atom and Sublime both misbehave this way--they've got syntax highlighting! They're already aware of block delimiters! Why don't they apply that knowledge to code folding?)

And I understand there are other reasons to not indent. In some languages, it's conventional to have certain kinds of declarations come at the beginning of a line, even if they're inside a block. (I think C++ does this, but I haven't used it since college--anyone want to comment?)

If such commenting is being done using the generic comment/uncomment keyboard shortcut, whether that happens is influenced by TM_COMMENT_DISABLE_INDENT in the language package's Comments.tmPreferences file.

At the time, I was attempting to modify a very large, nonbranching clusterfuck of a function, and there wasn't time to properly refactor it, so I wanted to examine each chunk and then fold it away once I'd determined that it wasn't related to what I was looking for. (And the code I was looking for turned out to be scattered across three different parts of the greater monolith, so I was glad I could fold away the bits in between.)

But yeah, generally it helps me get a high-level overview of the code without getting lost in the details.

I regularly fold all methods to get an overview of the class and its flow. Or if I quickly want to scan the class to maybe find something.

Or even just to go into "zen mode" to feel that I can focus in on one method while the other ones are "gone".

Emacs and vim are classified as text editors, and Sublime is a small fraction of what Emacs and vim are.

  I don't think it's quite fair to classify
  Sublime as a text editor.

While I may not agree with the totality of what @_RPM states, there is no doubt that Sublime is "a text editor" when the official site states thusly[0]:

  Sublime Text is a sophisticated text editor...

0 - http://www.sublimetext.com/

Because there is code in there that neither myself or my peers have seen.

Text editors are one of the few very-well specified systems. The requirements are very well known and there is plenty of information available on design and implementation. Yes, text editors are very easy to implement.

The problems come when people think it's so easy they can just jump in without doing any reading.

If only it was a raw win32 C++ app...

I thought Sublime is written mainly in Python?

Python actually, IIRC

That's not why Atom feels slow. You're running a machine that can run JS faster today than any machine could run C 10 years ago. There haven't been any major innovations in text editor technology in that time, none that would warrant such a huge slow down.

Atom feels slow because it's over engineered. They try to make everything run through the plugin system.

I am using a highly modified version of Markdown, with Monokai extended package.

super interesting! I'm thinking out loud: could be possible that there is niche waiting to be untaped with new tech–tools for lawyers (and others professions)?

Edit: I mean, no high–tech, but tools with a higher level of complexity where the UI isn't a dumbed down version, and where the software exposes some functionality to a better skilled user. I'm thinking the "millennial" professional, should be more comfortable with software and pushing the limit a little bit.

For what its worth, I've been using the dev channel for a long time and have never had any issues. It's very stable. I'd recommend it.

>Looking at the change list, it notes that there won't be artifacting with theme changes any more? If so that's freaking huge. For a while there it would start up, the package manager would update stuff, and then the interface would sorta crap itself.

How is that "huge"? It happened at most 1-2 times a year, and a simple 1 second restart fixed it -- and still left all the files you had loaded.

I don't uset ST but the procrastinator in me checked their home page, the download button defaults to ST 3.

So not supporting Redhat the #1 Linux commercial product is fine? The vast majority of commercial Linux is RPM based.

The issue is they should just have it automatically build RPM with the DEB if you have a DEB it isn't diffecult to so a RPM.

There is NO RPM and is the reason for the rant.

normal strings with "\" line continuations.

While not a sublime, I frequently switch iterm's themes when I code outdoors. A dark background is my preference, but a light theme works much better in sunlight.

It's not that people often switch themes, it's that when you open Sublime, Package Manager updates themes and it has to reload them, which used to cause the UI glitches.

Wow, thanks for responding! Very impressive work.

I don't look at the version number only, but at the changelog, too, but didn't pay much attention, until now.

Most sane projects create a build and test it, and don't rely on testing source code because the build process itself can cause defects as well.

What we've been testing as a dev build should have been promoted to stable, but, I realize now, he has the changelog embedded in the executable, and it's possibly merged across dev builds. He also has differences in the functionality between the dev and beta builds as you can't run the dev without a key.