[coldtea]

>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.

[gotofritz]

> 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.

[coldtea]

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?

[gotofritz]

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.

[coldtea]

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.

[gotofritz]

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

[cs0]

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

[gotofritz]

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