What's the vision for Sublime Text?

[karolyi]

FWIW, your approach to editors is the same as mine, and it’s what has paid off on the long run for me, having spent 25+ years on this road.

Before Sublime, I was a hardcore vimmer/gvimmer, and I still use it for quick editing in terminals. If there’s a window system, I use Sublime.

I’ve tried all kinds of editors, ATOM, VSCode, Pycharm, Jetbrains Idea, Netbeans and all the likes. Each time I try out something, I find myself gravitating back towards Sublime Text again. Bought the license, and would buy it again, if there would be time for it (which I think it is, considering the amount of money I earned with it).

All the newest hype about VSCode being the ‘next big thing’ is just garbage talk to me. It’s an awful slow monster to me. I can supplement ST with it, when ST doesn’t happen to work, but that’s the only time I’m willing to use it.

I don’t care about packagecontrol.io not being ‘streamlined’ enough or whatever the current buzzword is. We are developers, so if something breaks or doesn’t work, we should be able to figure out what it is. Not that if happens that often.

As far as I’m concerned, Sublime is the single best editor for windowing systems, and I’d like to keep it as is for a long time.

That said, is there a way go get our hands on the windowing system it uses?

[djspiewak]

I want to echo whole-heartedly what @wbond said about tooling philosophies. That continuum is a very important one to recognize, and it’s also important to understand that it’s not a continuum between “good” and “bad”. Everyone needs to identify where along that spectrum their workflow falls, and what they subjectively want.

I love Sublime’s minimalism. I love the fact that it’s extremely “batteries not included”. I even love the fact that Package Control doesn’t try to integrate a web browser or marketplace and basically just gives me the absolute minimum necessary to install things. That’s exactly what I want out of an editor.

In a sense, it’s kind of like a modern Emacs experience without (most of) the self-hosting or the performance issues. And that’s exactly what I want. It’s definitely not for everyone, and I think VS Code certainly falls at a different point along this spectrum and carries a different set of tradeoffs, but I am extremely happy with what Sublime does and how it does it.

And for the record, just as a marketing data point… I would gladly pay for a 4.0 license, today, even if the only major change to the editor was the addition of the minidiff. That’s partially a reflection of how awesome that feature is, but also a reflection of how happy I am with Sublime Text in general and how much I am in favor of supporting it.

If the vision for Sublime Text is simply “do exactly the same things we do today, in the exact same way we do them today, but slightly better and slightly faster”, I’ll buy that vision every day of the week.

[braver]

If you see something on the market that you like, then that’s great. The answer for competitors in that market is not to be more like that thing you like. Instead it’s to find their own strengths and consider that not all people like the same things.

Sure, new editors are more exciting than old ones. VS Code will eventually stop being exciting too. Right now it’s not old enough to have packages that haven’t needed maintenance for years. It tries to do so many things that it can’t help but be busy playing catch-up with all the tools it tries to replace. Atom also has lots of releases all the time. Why? Because it also wants to be a git client. That’s awesome, and if you’re still new to the command line and git and debuggers and all the stuff you need to learn to use as a developer, VS Code is a great starting point. At some point you may want to use a real fully featured terminal, use more of git’s features than simply syncing changes, etc. And you may find your all-in-one solution falls short. Or not. But you will inevitably come to understand that not everyone likes applications that are on the IDE end of the scale.

[hbar]

I don’t code much, but ST is my editor of choice, for pretty much everything. I use it in vim mode (neovintageous) because I find vim not performant enough when you start adding auto-completion, snippets and all that. ST is the only non-FLOSS software I use on my machine. There is no good alternative to it.

Having said that, there is one feature for which I keep searching in the changelogs, which is a gutter API. From what I understand, it’s not possible to have true relative-numbers (which is something I use frequenty in vim) and it pisses me off. I wonder if @wbond plans to support that anytime soon?

[rckt]

As @zhongjis mentioned

Looks like people are leaving and it hurts to see all those packages I use haven’t been updated for years.

So, probably, ST just doesn’t meet market demands anymore. And maybe the way to

do exactly the same things we do today, in the exact same way we do them today, but slightly better and slightly faster

is not the right one if ST wants to stay afloat.
My main concern is how to have all those plugins up to date if maintainers don’t see ST as something that is worth their time anymore. And without the community there is no product.

[facelessuser]

My main concern is how to have all those plugins up to date if maintainers don’t see ST as something that is worth their time anymore.

That’s a problem with any editor that has community plugins. But you can always fork a repository and support it yourself if one falls into an unsupported state.

And without the community there is no product.

Nah, it is still awesome regardless. There are a number of people that run Sublime with little to no plugins, and you can always write your own.

If you are really concerned about plugins no longer being supported, you can contribute monetary support or time to help keep them running.

[FHTheron]

Regarding package rot, I opened VSCode just now to quickly compare last-updated timestamps of some of my packages. I realised something and I’m wondering if it has been done by design.

Short: VSCode gives you more info in the editor to dissuade you from clicking on page or repo links. This info does not include any dates/age info. ST PackageControl gives very little info and you have to go to the website for more info and there immediately see date/age info.

---

The extensions view in VSCode contains a lot of informations. More than enough to prevent me from clicking on a link to go to the extension’s web site or repository. It does not show any dates. The Changelog, if an extension author bothers to create it, also will only show dates if the author puts them there. I think this is in anticipation of packages getting abandoned over the coming years and it is an attempt at dampening the “abandoned package” feeling.

With ST the package list is so minimal that you don’t expect to see any dates. You expect to have to go to packagecontrol.io to find any info that does not fit in the one in the list.

So, perhaps we can make a conclusion in favour of ST:
ST - no delayed disappointment. In ST, I avoid installing an old package if there is a newer one or if I don’t really need it. This means all the packages in my active list work. If a package is old and I still want it, I try it anyway. Often packages I want are only about 10 lines of python code that I’m just too lazy to do myself. Such a package really doesn’t need updates every month and if it does, I’d worry what on earth could be wrong in those 10 lines. It’s also often easy to use such a package as reference and tweak it locally to do what I want.

VSC - delayed disappointment and undo. In VSCode I sort search results by install-count and start looking through them. The first one that seems to do what I want gets installed. If it’s an old extension I don’t know it, unless it doesn’t work. So I need to install, try and uninstall an extension that doesn’t work and then wonder why so many people have it installed if it doesn’t work. If it works, I never think about it again and happily use it.

[rckt]

But you can always fork a repository and support it yourself if one falls into an unsupported state.

Yeah, that’s true but in this case I have to do it. It’s like saying that I can always repair my car myself in case all the services in the area stop providing their service for this specific brand. It would be easier for me to just change the car. And that’s exactly what’s happening to the community. People are simply changing their editors.[quote=“facelessuser, post:16, topic:41822”]
Nah, it is still awesome regardless. There are a number of people that run Sublime with little to no plugins, and you can always right your own.
[/quote]
Yes, but that’s not what @zhongjis asked in his first post. The question was whether ST is going to last and for how long?

If you are really concerned about plugins no longer being supported, you can contribute monetary support or time to help keep them running.

People who stop developing their plugins for ST do it not because of money, but because they don’t see ST making any progress in terms of API.

[facelessuser]

People who stop developing their plugins for ST do it not because of money

I’m a plugin developer. It would certainly help motivate me for some of my plugins. The underlying reason I developed then is not money, but I’m busy, and support a lot.

Yes, but that’s not what @zhongjis asked in his first post. The question was whether ST is going to last and for how long?

No one can answer that, not really

[rckt]

No one can answer that, not really

If I saw an answer like this from a product owner I would definitely reconsider whether I should spend my time and money on it. If the devs don’t have a plan for ST then they should either give it to the community or just shut it down. Otherwise the fastest editor on the planet is just going to fade away.

[FHTheron]

The question was whether ST is going to last and for how long?

It’s more fun to wonder about the future of Atom and VSCode (now both Microsoft owned and electron based). https://www.reddit.com/r/AMA/comments/8pc8mf/im_nat_friedman_future_ceo_of_github_ama/e0a235q/

And I also wonder if this question is asked as much on other editor forums as here. I don’t find anything for Code::Blocks for example, and there are many more editors that have been around for a very long time without worrying about adding shiny new bullets to release notes.

[rckt]

there are many more editors that have been around for a very long time without worrying about adding shiny new bullets to release notes

As I mentioned earlier, for me as a consumer, it’s not only about the ST updates, but also the plugins that stop being maintained. I’ve just gone through my plugins list and more than half of them had their last update more than a year ago.

[facelessuser]

But is it a problem that a plugin hasn’t been updated in a year? Sometimes yes and sometimes no. Some of mine haven’t been updated in a year because their is no reason to. But yes, for any editor, people may lose interest in supporting their plugin, because it is work. I say, support your plugin developers. Life is more complicated for me than when I first wrote some of mine. I still support them, but I do as I’m motivated and have time.

Volunteer time, money, or help answer questions. People always say they don’t want to support plugins they are interested in, but complain when a developer can’t find time to provide support themselves. There are many reasons why a developer may not have updated their plugin.

[addons_zz]

Can anyone tell me which direction is Sublime heading to?

It is going to keep a closed source project, and occasionally, new versions with new shiny little things, one at time are going to be released. And the more fanatic community users are going to keep maintaining their packages, helping users on the forums, and defending Sublime Text over anything else with their tooth and nails, even if they are not paid to do so.

Or maybe I just haven’t experienced the beauty of this editor?

The beauty of Sublime Text is, it is fast, has a very big API and thousands of legacy packages. Its ugliness is, it is closed source and the only way to change core things is asking them, and hoping they agree with you.

The beauty of other concurrent editors like VSCode is, it is open source and you can change core things without asking anyone else for it. Its ugliness is, it is slow and some people are ranting about security flaws of electron.

The beauty of other concurrent editors like PyCharm is that, they can may be offer user support promptly and help you figure things out more easily.

I really don’t want to switch but all those new features from other competitors are so luring to me now lol

You do not have to switch, why you cannot use both, Sublime Text and something else?

Some years back, I have been using at the same time Eclipse, Visual Studio Professional and NetBeans, both for the same project and files.

Nowadays I will be using both (Sublime Text and VSCode) because each one of them has their flaws. Today I use more Sublime Text other than VSCode because over the years I had built a lot of things for Sublime Text, and they really help me to work. But in the long term, i.e., several years from now, I will probably have developed more things for VSCode other than Sublime Text. Therefore, I will use more VSCode other than Sublime Text. I had recently rant quite a lot on this other thread:

Sublime Text versus Visual Studio Code in 2019

I am replying @cruzd in a new topic because things got messy and I may be wrote a little too much. So far, after a few years using several tools, I just never had found any tool which could adequate better for my customizations/improvements other than Sublime Text. But nowadays, I think Sublime Text reign/empire may be threatened by Visual Studio Code. For starting, use https://github.com/SublimeText/sublime_lib to interact with Sublime Text API, because it should improve accessing the Subli…

In the future, I may be find something else more shiny than Sublime Text and VSCode, then, I will be using both Sublime Text, VSCode and the New Other Shiny Thing I had found. Or I will just get rid of Sublime Text and VSCode and use only this New Other Shiny Thing I had found.

[zhongjis]

@addons_zz @facelessuser @rckt @FHTheron @hbar @braver @djspiewak @karolyi Thank you guys for replying! (sorry it only allows 10 mentions for each post) It is awesome to see your inspiring answers here;)

So…

I am also a type of person use Sublime just an editor and run everything on command lines. Like I mentioned before, I love sublime because of its lightning speed. However, I am also craving for those fancy looks and features of other editors.

Here’s what I am thinking after reading all the posts here:
For Sublime text, the editor itself is doing an awesome job as simple and fast editor. However, developers maybe can spend more time on connecting normal users and plug-in developers, such as having a comment section under plug-in info. The reason for this is that I believe not every one of us will go to the plug-in repo pages and check what’s on there. I know people can also come to the forum to talk about plug-ins but I believe there’s an issue with this approach.

Also, it will be awesome if we can just click one button to download the plug-in on Package Control site! @wbond

I guess it will also be awesome to add the last updated date or software compatibility/build status info in the app (under package description). Sometimes it is such a pain for me to guessing if my plugin is working instead of just seeing the build status somewhere …

Again, thank you for all the replies so! Let’s keep this topic going and happy coding

[flashios09]

I used ST for more than 3 or 4 years and i love it
recently i moved to VSCODE for two reasons:

1. Git integration, i think this is the most feature that ST users wish they have

2. Typescript with autocompletion, this is crucial for a frontend dev

i still use iTerm not the integrated Terminal inside the editor

[jfcherng]

I am not a frontend dev but I think the best autocompletion I could have is provided by a language server.

Disclaimer: For the following contents, I do not give it a try for Typescript (but I use a PHP language server indeed).

You may set up LSP + one of language servers for Typescript.

• https://github.com/sourcegraph/javascript-typescript-langserver
• https://github.com/theia-ide/typescript-language-server

[gorrie]

I left ST a couple years ago and find myself coming back to ST for small tasks that I know it will particularly do well. There are a few reasons that keep me from using ST as my main editor:

1. Its not open source. I know this is unlikely to change but as a plugin developer I like being able to see the source code affect my plugins and being able to make changes as required.
2. Subtle features missng such sidebar enhancements typically included by default into other editors
3. Improved UI and API to support the UI so the developer can add git integration etc. UI improvements I would like to see implemented are:

• Activity/Tool bar similar to that used in VSCode and will remain invisible until a plugin requires it.
• Panels similar to that used in Atom. Realistically this is just a variation of a window that provides visual changes that make it look like sidebars and a footer bar with toggle to collapse and expand. The example link uses panels for git intergration. https://goo.gl/images/unqQfg

4. Finally package control installation built in packagecontrol.io/installation

They may not seem like much but I think its these subtle features that make the difference and would attract developers back to ST.

[MeirG]

Why not having the users’ community lead the vision???
By this I mean to have a voting system on feature requests. In this voting system, each registered user could post a feature request. Such a user will also have ‘n’ votes (n between 3 and 5 I would suggest) for her/him to cast in favor of a given feature.
Another “voting” method could be by establishing a crowdfunding project for each feature request. Here anybody can “vote” and give a different weight or priority by pledging different sums of money. The capital raised will go to the ST HQ to actually implement the feature. The target sum for the crowdfunding will therefore be set by them.
Well folks, vote on this proposal by “likes”.
Edit:
Well, you might lookup Sublime HQ Pty. response to this idea of mine in this thread (towards the end) to my initiative to raise funds by crowdfunding for the implementation of BiDi support in ST3 (ST4?)

[schrodinger_cat]

Just linking my thoughts for Sublime Text going forward here as it seems relevant to this conversation: Sublime Text going forward