It doesn’t. CSScheme is technically just a different syntax for achieving the same functionality as tmTheme files do. It does some processing for color values, but other than that pretty much nothing.
Now, its main advantage stems from being able to compile CSScheme from Css preprocessor languages like SCSS, which do support variables, nested selectors and control structures (and macros of some sort).
That already works for phantomCSS and popupCSS elements for Color Schemes as Will has documented in the predefined variables section at the very bottom of http://www.sublimetext.com/docs/3/minihtml.html.
Okay. I understand this. YAML is fine, too. Almost everything is better than XML 
I think one thing that would help is a fully featured, boilerplate-like theme we could use a starting point every time we create a new theme, so we know that everything is included. Maybe somewhat add everything and give option to set some null value for things that shouldn’t be styled but still be listed in the theme YAML code.
I would suggest Monokai as the default theme, because it’s awesome!
Also some good docs are much needed. Shouldn’t be too rocket-science-like creating a good theme 
The scope naming docs provide a list of suggested scopes to highlight:
https://www.sublimetext.com/docs/3/scope_naming.html#color_schemes
I agree although it depends on how is the XML is formatted:
<highlight scopes="invalid" fg="red" bg="white" fontStyle="bold">
Would be IMO much better to type (would prevent us from having some files with thousands of line for not much actual content in the end).
I agree. Using XML attributes would be better than YAML. Putting the scheme definitions one per line is much more useful.
It’s similar to how vim color schemes are defined (Vimdocs: http://vimdoc.sourceforge.net/htmldoc/syntax.html#:highlight):
Plugins being able to provide “partial” color schemes would be great too. Vim color schemes allow plugins to “link” to highlight definitions in the enabled scheme (if they are defined) or else define default ones.
For example:
Say you have a color scheme (monokai).
highlight DiffAdd guibg=#13354A
highlight DiffChange guifg=#89807D guibg=#4C4745
highlight DiffDelete guifg=#960050 guibg=#1E0010
A plugin, say GitGutter, can link to those color definitions without defining specific colors.
highlight default link GitGutterAddLine DiffAdd
highlight default link GitGutterChangeLine DiffChange
highlight default link GitGutterDeleteLine DiffDelete
The plugin can also set default colors if the “links” don’t exist in the enabled color scheme. So plugins can provide default colors for its features and color schemes can support the plugin with scheme overrides. For example, the git gutter plugin could define scopes suffixed with “.gitgutter” and the color scheme can define generic scope definitions.
# scheme
highlight diffadd guibg=#13354A
highlight diffchange guifg=#89807D guibg=#4C4745
highlight diffdelete guifg=#960050 guibg=#1E0010
# plugin
highlight default add.gitgutter guibg=green
highlight default change.gitgutter guifg=orange
highlight default delete.gitgutter guifg=red
highlight default link add.gitgutter diffadd
highlight default link change.gitgutter diffchange
highlight default link delete.gitgutter diffdelete
All the above can done better with XML attributes opposed to YAML.
For the following XML:
<highlight scopes="invalid" fg="red" bg="white" fontStyle="bold">
The equivalent YAML is:
- {scopes: invalid, fg: red, bg: white, font_style: bold}
Note that Sublime Text has much better YAML highlighting than this forum does.
I see no reason why you can’t use a single-line YAML dictionary if you are going to use XML attributes or some custom format.
Either way, we are getting pretty off topic now. If you want to discuss the topic more, let’s split to a new thread.
Back more or less on-topic. Sublime is my go-to tool for pretty much all development work and despite a growing list of annoyances and nit-picks is still a beautiful editor and a really “nice place to be” during the countless hours of development workflow over the last years.
However - echoing comments from many friends and colleagues who are also Sublime users - it’s becoming an increasingly niche product for essentially the following reasons:
Points 2-4 above are all compounded by 1, and frustration amongst colleagues is further compounded by the need to keep switching to other tools to do certain jobs that are awkward in Sublime for one reason or another. Ultimately such frustrations will reach a cut-off point for most, especially given the tech-savvy audience for a product such as Sublime, and were the main reason I switched to Sublime from my previous editor.
One of the reasons programmers get so passionate about editors is that it’s such an important part of development workflow. A good editor saves time and facilitates reduction of repetition. A great editor is a beautiful place to be that makes your code & projects come alive and simplifies complex project navigation, growth and rework. Sublime still ticks many of these boxes, but there is a sense that it could be so much better.
It is my hope that the 4 points above form a loose basis for Sublime’s evolution moving forward and that these comments are taken in the intended spirit ie. as positive, constructive criticism.
Here are my, not Sublime HQ’s, thoughts:
This probably depends on what you want different than what Sublime Text has right now. In 2016, we released a bunch of builds, and if I recall correctly, a similar number to the Atom and VS Code teams. Perhaps the features added aren’t interesting to you, but there is a lot that can be seen at https://www.sublimetext.com/3dev.
Generally we don’t post about what is coming next because priorities change, and sometimes ideas don’t pan out. That said, I hope you all will enjoy what is going to be part of the next builds!
Part of this is probably how you think about it. From my perspective it isn’t so much that there are limitations on the API, as the current implementation of various aspects are purpose-built and aren’t abstracted in such a way that you can just expose a way for Python to interact with them. Instead, adding APIs requires taking the current, efficient implementations, thinking about the way in which people will want to use them, and then re-implementing them to remain efficient but also allow for the API to interact with them.
I’ve done a bit of behind-the-scenes work during this last cycle, in addition to much more obvious changes. A good chunk of the work I did will only be visible as performance improvements and edge-case bug fixes, but the core implementation has been rewritten and paves the way for future improvements.
A lot of developers expressed interest in HTML and CSS support, so 2016 added lots of features in that area (lots of features implemented in minihtml, phantoms support). We made huge improvements in syntax highlighting accuracy and speed, and set guidelines for the community to use in continuing to improve syntaxes. The Python environment got updated, with modern versions of OpenSSL and SQLite, plus backports of various bug fixes from Python 3.4, while retaining full compatibility with all existing plugin code. We added API controls for various parts of the UI (sidebar, minimap, panels and tabs) and added hover controls, which enabled mouse-based code exploration through the Show Definitions popup.
I have been working through various bugs and nitpicks, focusing on more serious issues like crashes or things that impede general usage. Many items on the issue tracker are enhancements, some are listed as bugs but the user just doesn’t like the way Sublime Text chose to implement a feature. With the number of Sublime Text users and all of the different operating systems it is used on (and new releases of operating systems), I am not surprised that there are a large number of issues opened. But yes, we are working on them. I try to make a point of closing issues that I know are resolved with each build, but I am sure some are not closed because they can be hard to find.
I should say a huge thank you to @FichteFoll and @kingkeith (plus all of the other users), who help to manage the issue list, marking duplicates and trying to provide extra information where possible.
Most of the limitations are a side-effect of other features. Large file and long line handling is at odds with full-file symbol indexing, word wrapping, variable width font support, minimap, syntax highlight performance & accuracy. Per-window process sandboxing is at odds with low memory usage and portions of the API. Lame (naive) code folding means that code folding works out-of-the-box for lots of crappy syntaxes that exist, at the expense of precise control. Package conflicts – without specifics, this is hard to talk about, but yes, there is a good likelihood that there be problems when running code from 20 different developers who run independent projects. Remote editing and slow filesystems are at odds with performance, symbol indexing, local file notifications, Goto Anything, and other features.
That said, it isn’t that we don’t plan to try to improve aspects of these areas, or implement layers on top to handle edge cases. I just think it is good to be aware that tradeoffs exist, and lots of the good that people love in Sublime Text is because we have to make tradeoffs, and because we decide to make local editing of source code and markup a priority over handling multi-GB log files loaded from a network share.
I hope that my perspective at least helps you to understand how I process the issues you brought up. I definitely see people expressing them. Part of it I think is comparing large open source projects run by huge companies, with a three person (two developer) company. In the end, I believe it is all a balancing act with priorities, maintainability, vision and a diverse user base.
It shouldn’t be Sublime’s goal to be exactly like editor X. I prefer Sublime exactly because it’s a bit more simple and a bit more naive. Code folding is a good example. I love how VS Code remembers my folds, even folds within folds. But I also love that in Sublime I can fold any region any way I want. You can’t reasonable expect to get it all and hence there’s choice. For my particular use cases other editors are super far behind and not even focused on making the changes that are important to me. e.g. the UX of dealing with build systems and inline errors are far superior in Sublime exactly because it doesn’t try to do too much, and last years improvements in this area were huge.
Horses for courses.
Thanks for your detailed reply Will. As mentioned in my original post, I’ve listed a range of points raised time and again by others in my circle together with my own thoughts. I’ll continue in that vein below…
It’s not so much that features introduced in 2016 aren’t welcome, more a sense that, given the limited development resources available, they come at the expense of requested features / improvements. That’s a judgement call by Sublime HQ of course - I’m just feeding back what I’m hearing time and again.
The first part of your point requires an understanding of the inner workings of Sublime to appreciate and, while no doubt valid, the fact remains that there are hard limitations to what extensions can do with Sublime. Given your request for API enhancement suggestions here in this forum, it seems as though this is on the roadmap. It’d be nice to see a number of those suggestions find their way into upcoming builds.
Given the efforts made to categorise issues on the tracker, it’s not hard to weed out bugs, nitpicks and FR’s. But I appreciate that some issues blur these boundaries.
Nevertheless here’s an example, and although this post is from April 2016 I reported the same issue on the forum, pre-bugtracker, way back in 2013. These sorts of problems are disconcerting and can potentially corrupt files, in this case with extraneous NULs. Another example is sliding marked regions up and down through folded sections which, while not corrupting data, confuses in practice.
These two examples are fairly trivial and have fairly easy workarounds. But there does come a point where you begin forgetting all the workarounds to these edge-case gotchas, and just wish they got fixed.
I also echo kudos to @FichteFoll et al. on maintaining the issue tracker.
These are fair points but, I would argue, not immutable facts. For example, with particularly large files symbol indexing and syntax highlighting isn’t necessary, and issues with word wrap, variable width fonts and minimap are all issues that depend upon implementation specifics which could be improved. On sandboxing, few users would open more than 5 windows in Sublime, and modern PC’s are more than capable of handling that kind of memory footprint.
I should apologise for using the loaded term ‘lame’ in reference to code folding. It is useful in its current form, but the lack of language intelligence and not saving folding state is limited compared with other editors, especially given that Sublime is armed with the lexical info needed to implement intelligent folding via syntax scopes.
Unfortunately, remote editing is something that almost every other editor gets right in terms of reliability and performance, and Sublime seems to struggle by comparison. A simple visual indication can be used to indicate remote files/dirs, in which case symbol indexing & local file notification won’t be available and goto anything can revert to a more basic form as necessary.
I don’t mean to sound argumentative here. Expectations are generally set by the ‘state of the art’ (so to speak) and Sublime can seem below-par compared with alternatives when, for example, it slows to a crawl when trying to open and perform simple edits on a large file or crashes when editing a file on an NFS share.
I appreciate these points, together with the time you’ve taken to consider those raised in my original post. In the end, we all want to see Sublime improve and be the best, most performant and flexible general purpose editor around. I look forward to see what the next builds bring!
These are fair points but, I would argue, not immutable facts. For example, with particularly large files symbol indexing and syntax highlighting isn’t necessary
That’s true. When opening a large file (and the editor knows that ahead of time, since it can stat the file size on disk), ST could disable certain features (and perhaps offer a way to re-enable them for users willing to take the slowness tradeoff).
On sandboxing, few users would open more than 5 windows in Sublime, and modern PC’s are more than capable of handling that kind of memory footprint.
For that, you’d be surprised on both counts. I’ve seen people in my teams that regularly have more than 20 windows open.
And a modern PC runs a lot more things besides ST, especially for a dev. Chrome, for one, perhaps several VMs or Docker instances, etc.
True. But with Chrome, open up enough tabs and windows and you’ll see your 16Gb RAM machine grind to a halt (I’ve been guilty of this!). Given such freedoms there’s always the potential for edge-cases but given the target audience I doubt this would present any real issue one a per-window basis. But even in the arguable case where automatic window sandboxing could present an issue, offering it as an option would resolve that.
Sandboxing could bring some real benefits to Sublime:
I’m not saying this (or any of the other points I made) should be done now or as a priority, just making the case for why they should be on the roadmap or at least discussed. In so doing with reasonably fleshed out suggestions, together with some kind of prioritising based on votes, Sublime becomes customer focused and its roadmap becomes clear to all. Features are planned, expected and provided in response to customer need in a loosely democratic model.
As an example Reaper, a digital audio workstation product, also has a small development team (4-5) in a closed-source model, but manages this quite well. Perhaps Sublime HQ can learn/improve here?
How do you imagine plugins interacting with this architecture? Isolate them as well? Startup time is not that low to make a new process (+ plugin container) for each window without it feeling slow to start up. Furthermore, plugins would lose cross-window functionality since they are isolated now.
There will be a lot of edge cases. There is a reason why it took Mozilla over a decade to make their browser multi-process.
You seem to know a lot about who is using this and how. However, it matches poorly to my experience. At any given time I may have several processes running taking up around 16 of the available 16 GB, and definitely over 5 Sublime windows on top of that. The fact that I have a lot of RAM doesn’t mean every app can be like “modern PC’s have plenty RAM so I can just go and take some more”.
Perhaps the way my colleagues and I work are corner cases, but the appeal of tools like Sublime is that they can be made to work for any corner case.
I know you mean well, but you’re making a lot of assumptions, downplaying or simply ignoring any downsides to your proposals, and you’re telling people how they should be doing their job. The perspective is welcome, but don’t assume to represent more than just another voice among thousands of users in amazingly varied use cases.
Sandboxing sounds like the most complicated solution with the most overhead, solving problems that don’t exist and implementing features no-one is really asking for. And it won’t work.
Not true. A sandboxed window or whatever is not sandboxed from everything. It still interacts with the the main process and the OS, giving it ample opportunities to bring them down. For example Chrome windows routinely crash Chrome and on occasion crash my Mac, which is otherwise very stable.
I’m not sure how you judge people’s feelings about software, especially when they’re based on a fiction. I guess that must fall into the realm of marketing, which routinely deals in such things. But here’s a suggestion: instead of sandboxing bugs (which doesn’t fix them), why not just fix them?
Not true. Processes are expensive compared to threads, which give you the same “SMP.” ST already uses threads.
None of what you mention has anything to do with sandboxing or separate processes, or require it, or are fixed by it. You can just fix those problems in the existing code with an appropriate design. The main difference is that launching will be slower if you have to create multiple processes.
Will not work. If there is a shared resource there will be scope for conflicts, and there are always shared resources. You don’t multiply the shared resources when you sandbox, you just put them in different processes. For instance sandboxing will mean that two plugins fiddling with the same user preference will still cause a conflict. Since plugins are generally triggered by resources, like a file of a particular syntax, or an edit in a particular buffer, the conflicts will largely remain.
From what I can tell ST is largely a one man show in terms of the core application, and I get the impression that that one man is bored shitless by a piece of software he’s maintained for years. I really don’t blame him, I’d feel the same way. There is probably not enough money in it to have a full team working on it, becuase not enough people are paying for it and there are free alternatives, or there is more than enough money in it for one man and that one man has no desire to go into management and complicate his existence while increasing his expenses. The “sole developer of a useful utility” is actually quite a common business model.
Usually what happens here is that the software is open sourced (unlikely), abandoned but still charged for (likely) or sold and reworked by its new owner (likely).
I using ST for so many years, so sad to see the current stage of this product(ST3).
How many years, this version is has been under development???
I am sorry for what I have to say.
ST is slowly slowly DEAD, it was the best the code editor for long time, but now webstorm and vs code are very good too.
but you drop it, doing minimum work in every year. just enough let people think ST is not dead project.
for last update was in — 23 September 2016, from today is 6 months ago.
you doing like this every year, for begin of year, you do minimum work, then drop it rest of the year until next year.
I understand you are busy. if you not care about ST, why you not sell it to other company which could really keep this product LIVE. it has been 4-5 years this version 3 still not complete.
I am a big fans with ST, but really not like the attitude of the development’s team or person.
hire more people to working ST or sell to other company whom care and will continuing development!
Jon and I did 23 dev releases in 2016, and three betas. Those numbers speak for themselves.
We spent a lot of time improving the language syntaxes also, with well over 50k lines of definitions changed.
Not all work is suitable to be released in small batches. Just to assure you, I work full time for Jon on Sublime Text. I would be pretty silly of Jon to pay me a full-time senior software engineer’s salary if he wanted to do the minimum of work.
The product and community are still very much alive. Over 800,000 users checked for package updates yesterday. In the blog post for the last beta release, Jon mentioned that we are almost ready for 3.0. Granted, the 3.0 beta is used by at least 95% of the users of Package Control, so changing the version to 3.0 stable is more of a symbolic thing.
Sublime HQ isn’t going anywhere and we are continuing to work on making Sublime Text even better. If you aren’t using ST3 because it is labeled beta, I recommend you try it out. There are so many improvements and fixes over ST2 that it would be a waste not to take advantage of them.
Just to clarify, Jon hired me to work on Sublime Text in January 2016, so there are currently two of us working on the core.
I am sorry for what I said here.
I am not to try hurt any one here. just express my sadness of current state of ST. many years, I was hopeful this ST3 final release, but it’s not.
we are all see the works has been done in development, but my opinion is that this is not enough.
many user like me, are looking forward the new version release, but for many years, it’s not.
if this is not enough people working on this product, the owner of ST should hire more.
we all have a good wish to ST. we all want to ST be better and continuing development more important to make money for your company…
and @wbond, if my words are hurt you feeling then I am apology for this.