This is not supposed to be another “ST is dead” discussion! ST is great!
I just thought it would be great to get a comment on current development activity or plans after all the activity last year. The last dev build is now from September 2016 and I thought there were plans for more regular updates. I know @wbond is active on the forum…
Thanks!
I’ve been working on a bunch of stuff, we just haven’t rolled it up into a release in a while. We should be doing a new build “soon”.
Hope there will be some improvement in gutter icons.
The limitation of only one icon per line is really annoying.
Especially that you can’t choose which one to display if more than one defined.
Follow up questions:
Default.sublime-packageColor Scheme - Default.sublime-packageTheme - Default.sublime-packagedocsify and find it great to work with. I suggest opening a repo on Github on the sublimehq userspace. I’d “translate” the unofficial docs to the new format if desired and merge them with the official ones. Also, I could add a German translation.
I recently came across docsify and find it great to work with. I suggest opening a repo on Github on the sublimehq userspace.
Authoring in HTML isn’t a hindrance on our current workflow, so I wouldn’t want to add more work to our limited team for something that isn’t a pain point.
I have in mind to discuss with Jon putting the docs on Github for contributions, but it isn’t high on (relative) priority list at the moment.
Would be nice to have these on Github for sending patches
The color scheme, other than Monokai, are effectively deprecated at this point. The community has made hundreds, if not thousands of colors schemes. The current ones in the default color scheme package woefully under-utilize the syntaxes we’ve been improving.
The theme isn’t open source, and I don’t think that is an area where the community involvement would make significant improvements. We want a reasonable out-of-box experience, otherwise the community is doing a great job of exploring the aesthetic that they like.
The Default package handles a decent amount of core functionality. Accepting patches on that isn’t something that would be as useful as work on the syntaxes or good bug reports. The other factor here is that backwards compatibility is a big concern. Package authors tend to tie into Python code from the Default package, so the APIs are effectively frozen once released. This prevents refactoring and other changes that aren’t strict bug fixes.
Where do we send patches? The lists keeps getting longer…
Deciding what is highest priority in terms of what we are working on is no simple task. Sending patches isn’t as useful as concise, well-written bug reports.
Sending patches would likely just lead to a disconnect in expectation. Patches will likely have unforeseen affects since the vast majority of the codebase is closed source, then the patch has to be rewritten taking into account all of the use-cases and edge cases that aren’t obvious. I’ve tried to grab a few patches, however they ended up having to be almost completely rewritten to handle situations that weren’t obvious, plus to match our style and linting setup (which isn’t public). In the end, the patches didn’t really save any time, but instead required that I try to interpret why the author was changing what they were.
There has been plenty of activity going on behind the scenes, as it typical with most development that isn’t open source. Once the next build is out, I’ll be visiting the issue tracker and closing everything that was addressed.
And yes, I understand people are eager to see the next build. I’m excited for everyone to get their hands on it also!
I was not implying that you have to meet any expectations on anybody’s end. I’m some random guy on the internet and whatever your choice to work on might be, I can work with.
I’ll go take a look at the syntaxes…
What modern color schemes can be used as a good starting point for the latest syntax improvements? Are there any good “base” schemes that showcase the latest syntax usage? I want to make sure my custom scheme isn’t missing out on anything great, but without a good reference, I may not know what I’m missing.
Check out http://www.sublimetext.com/docs/3/scope_naming.html#color_schemes for the current “best practices”. Further up on the page explains our standards for the default syntaxes.
Just an observation: let’s all remember last year’s „is sublime dead?” weekly posts, when there was no sign whatsoever from @jps vs. the current situation, where @wbond is trying to reply to most/all questions, being active everywhere.
I start to believe that what Jon really needed was a PR guy 
@wbond I think ST is still the best Editor out there. I tried Brackets, Atom and BBEdit and came always back to ST due to speed and customizability.
I do a lot of code-intense Jekyll-Projects with a lot of different syntaxes (php, yaml, liquid, html, sass/scdd, javascript, python etc. In this scenario ST really shines.
Keep up the great work and spread the word.
Best regards from Germany, Leo
@wbond I really love ST3, but there is only one thing that I would really love to see and it would be a good reason to drop Atom for some people:
Having the option to style and create themes via CSS or any other clear, open and simple solution. If this will be implemented, people can’t argue anymore that customizing themes is hard in ST3.
What’s your opinion on this?
Well. I dislike these plugins because they generate not the best theme code.
My way of doing things is that I look at ST3’s Monokai theme and then just change the color values. So, I do not miss a lot of special syntax things because this theme is pretty good, but this method is a big pain in the a*s…
Please elaborate on why you think that CSScheme creates suboptimal theme code.
For someone who is familiar with CSS, I could see how CSS would feel like a simpler option. I also understand why people dislike all of the extra markup in XML. That said, I don’t know if I would consider CSS the best option, since there would be lots of inapplicable aspects, selectors and concepts.
In my mind the most complicated part is knowing what scope names to use and what they represent. Significant work has gone into solving this problem in the Scope Naming Guidelines. Some more work needs to be done there, and I need to write some official docs about color schemes and all of the various features we support.
If I were to pick a format for specifying color schemes right now, I would pick a YAML format similar to what we use for .sublime-syntax. That gives us a fairly generic format, without lots of extra syntax to distract from the meat of it. Variables and color functions could be implemented to make it easy to blend colors and specify things in HSL, RGB, hex, etc.
I’ve done a bunch of theming in Atom, and as I see it the benefits of CSS-based theming comes down to two things (basically in agreement with what you’re saying here):
The first can be achieved by replacing the xml with something else. Preferably with something that supports variables, since you’ll be reusing the same color a lot. But besides the syntax it already basically works like that and there are ways to write yaml or json and convert it.
The second is just something you don’t have if you’re not in a browser. Inspecting the underlying scope structure is kinda hard in anything that’s not a browser. But this is the real game changer that makes Atom easier to style if you’ve ever done any web development. Perhaps we could have a tooltip for the scope inspector that follows your mouse cursor as you hover over the editor?
I agree for me that CSS is great for theme (I’m using CSScheme). I haven’t tried if it works with CSScheme, but for the variables, CSS now supports this too:
html {
--red: #f00;
}
invalid {
color: var(--red);
}
Generally the idea that you need to be inspecting the dom to build a color scheme makes me think it is too complicated. It also makes me think there aren’t good docs for what classes should be used to create a color scheme. Sure, for someone who does web development for their job, this is likely familiar, however I think we can do better in Sublime Text considering our limited scope. 
Have you seen https://packagecontrol.io/packages/ScopeHunter?
Built-in there is also the show_scope_name command. This shows you the list of scope names where the cursor is. Generally this is used mostly when writing syntaxes, to ensure you are properly applying scope names. Color schemes will mostly benefit from using general scope names, based on the list at http://www.sublimetext.com/docs/3/scope_naming.html#color_schemes.
Hello,
I have been using ST3 for quite a long time now. I really love the speed of sublime but now with others IDEs such as PHPstorm and editors such as Atom, i feel like sublime is really lagging behind.
I have tried using PHPStorm, but it was not my thing really. I don’t like IDEs. Now i am currently using both ST3 for my personal projects and Atom for work because of the packages available such as SFTP, git+.
I hope to see much improvements in ST3 soon. I hate using many tools at once.
Thanks and keep up the hard work guys.
That is kind of a big advantage. Even if it’s more complicated than necessary, but if you’ve been working like that for years, it’s still easy to get into. I’m not saying that building an editor on web technology is a good idea for that reason though
Have you seen https://packagecontrol.io/packages/ScopeHunter
Oh, yeah, well that’s done then 