It was great when it came out, but now Atom is better.
It was great when it came out, but now Atom is better.
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.
> 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.
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?
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.
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.
>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).
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.
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.
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.
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.