ST3 Plans? What happened to all the activity last year?

[braver]

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.

[qgates]

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

qgates:
1 Pace of progress.

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

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.

qgates:
2 API limitations.

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.

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.

3 Bugs/nitpicks.

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.

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.

qgates:
4 Specific/core limitations.

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

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

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!

[hejazzman]

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.

[qgates]

qgates: 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:

1. General stability. In the event of a crash, you'd only lose the current window/project, and not all 10 you have open and in various states of modification. Most users get a 'feel' for what is potentially less reliable in Sublime (eg. editing files over network shares), and could simply open a new window prior to such operations without fear.
2. Increase confidence. At the moment, I'm hesitant to open certain kinds of files (large, long lines) without first saving out and closing everything else, or opening them in another (portable) physical copy of Sublime.
3. Improve performance. Separating Sublime windows to the process level means that each can take advantage of the underlying OS'es SMP ie. backing off background processes in favour of foreground ones. So eg. if a large file is making Sublime window X slow, Sublime windows Y, Z are still nice and snappy because window X in the background won't steal CPU cycles from foreground windows.
4. Improve command line launching. At the moment, use of Sublime from the command line is a bit of a mess. If Sublime isn't running, it'll launch with all its previous tabs/windows. If it is, it'll open a tab in some window. The flag for new window is unreliable in terms of the window that receives foreground focus. And Sublime's performance with the launched file(s) is compromised while Sublime rebuilds indexes for all the other opened windows, syntax-colours their files etc..
5. Facilitate per-project and per-window enabling/disabling of plugins. This mitigates plugin conflicts to some extent by allowing plugins to be enabled by context, ie. what type of work is being done. So if I'm working on a project involving PHP, PHP plugins are enabled, but when I'm working on a Java/Android project they can be disabled in favour of Java/Android plugins.

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?

[FichteFoll]

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.

[braver]

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.

given the target audience I doubt this would present any real issue

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.

[nutjob2]

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.

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

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

3. Not true. Processes are expensive compared to threads, which give you the same "SMP." ST already uses threads.

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

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

[sunlihao3000]

@wbond

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!

[wbond]

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.

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.

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.

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.

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.

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.

[wbond]

From what I can tell ST is largely a one man show in terms of the core application

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.

[sunlihao3000]

@wbond

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.

[Sasha_Chernykh]

with a three person (two developer) company

@wbond,

1. Do I understand correctly that only you and @jps works in Sublime Text private code and get money for it?

2. You discussed to make Sublime Text open source? I understood that you are very very good programmers, but I think that 2 developers is small for such a large-scale project as Sublime Text. Other developers could accelerate the development process and fix issues.
   
   I may be wrong, but it seems to me that the Sublime Text can grow less intensively than Atom and other open source text editors.

Thanks.

[wbond]

Do I understand correctly that only you and @jps works in Sublime Text private code and get money for it?

Yes, that is correct.

You discussed to make Sublime Text open source?

I can't speak for Jon on this regard. However, imagine you spent more than ten years of your life coming up with a great product, building something unique and powerful, and making sacrifices along the way. Would you just give it all away and go find something else to make your living from?

Not to mention, running an open source project generally involves much different work than actually building a product.

[braver]

Not to mention, running an open source project generally involves much different work than actually building a product.

Also, it's much more work than people generally think. Pretty much all successful open source projects are backed by large companies that are able to make the necessary investments to keep large teams afloat (lots of costs and no way to earn anything back). The Atom team for instance is pretty big and they spend a lot of time coordinating the community.

I'd say a focussed team of two developers is more likely to develop a great product than to manage a sprawling open source project with as many users as Sublime. Of course, you have to design well, keep the codebase small and be focussed. All of which are important anyway, and exponentially easier to do if there are fewer people involved.

This approach probably means Sublime has different goals and priorities than Emacs (extensibility), Atom (be even more extensible than Emacs), VS Code (tightly integrated Typescript development), TextMate (a proper editor for OSX) etc. Which is fine, because if they are doing those things, Sublime can be free to do something else. Maintaining feature parity with competitors is only one strategy, it's not necessarily the smart thing to do. The fact that we're even discussing this considering the editor landscape today, could tell you that it's offering something that's compelling all by itself.

[Chipotle]

I'd say a focussed team of two developers is more likely to develop a great product than to manage a sprawling open source project with as many users as Sublime.

TextMate is another interesting example here, in a sense—they've gone open source, and we don't really hear much about them anymore. TM2 is still being actively developed, but it doesn't really have a sense of being thriving. On the flip side, BBEdit is also being actively developed, and every major release brings some pretty cool stuff. (It vies with ST as my favorite editor, depending on the task at hand.)

Also, +1 for the shoutout to Acorn.

[Mana]

Sublime HQ isn't going anywhere and we are continuing to work on making Sublime Text even better.

Super glad to hear this. I like ST3 a lot, but worried about it being abandoned due to the lack of blog posts and twitter comments -- so I decided to check these forums. Your replies throughout this thread have been very, very encouraging to me!

[ionFreeman]

I'm a longtime TextEdit user. I started using Atom last year, and I'm dissatisfied with its responsiveness, so I installed Sublime Text 3 today. All of which is to say, I'm new here, so I apologize if this is a delicate question.

When do you all expect SublimeText 3 to come out of beta? What's the outlook for GA?

[jnials]

Hmm..... I won't speak for the powers that be. But ST3 is pretty solid. My guess is it will come out of beta when Jon and Will decide it is ready. But there's no reason not to commit now. You pay now you will still have access to the full version. I'm just waiting for upgrade pricing for ST2->ST3. But my ST2 key has worked throughout.

[jfcherng]

Sublime Text 3 "Beta" is stable enough in my opinion.

[bijan]

..... I won't speak for the powers that be. But ST3 is pretty solid. My guess is it will come out of beta when Jon and Will decide it is ready. But there's no reason not to commit now. You pay now you will still have access to the full version. I'm just waiting for upgrade pricing for ST

https://www.sublimetext.com <= It's not really beta any more. They just forgot to remove "Sublime Text 3 is currently in beta. The latest build is 3126." from the download page. I guess it's just there as an excuse to make changes whenever Jon wants.