Sublime Text going forward

[schrodinger_cat]

First, let me say I love Sublime Text, it’s being (and still is!) my go-to text editor for ages. We all know why it’s good: it’s an incredible piece of software with beautiful UI, powerful API, and unmatched performance.

However, we also all see how it’s popularity is vanishing in favor of Visual Studio Code. Valuable members of the community are moving away from Sublime, some even going as far as proclaiming Sublime Text is dead. I certainly don’t share this sentiment, but the combination of Microsoft sheer workforce and power of the open source community is hard to beat, no denying that.

VS Code has a ridiculous amount of useful features and an extremely fast development cycle. But this all comes at a cost. And this cost is performance. Even though it’s the most performant and well optimized Electron-based app out there, it’s still not even comparable to Sublime Text.

So… we have one ace up our sleeve and force against us we can’t beat. Here is my plan.

The most important one

I believe debugger support in VS Code is the most popular reason why people are migrating to VS Code (dah!). It’s just so much nicer to debug your code right here in the editor. Although we have a couple of plugins that add debug support for certain languages, they are hacky, have clunky UIs (different for every plugin!) and not well maintained. It’s just not good enough. We need a native debugger interface and a good way for the community to add new debug targets.

What new way?

Instead of trying to beat something we can’t, we should embrace it. VS Code is made using a very modular approach offloading language support implementation and debugger implementation to separate parts using Language Server Protocol (LSP) and Debug Adapter Protocol (DAP). We could and should benefit from these incentives. We need first-class support for both protocols in Sublime Text. Again there are admirable attempts to add DAP support to Sublime Text using plugins, but they are ultimately failing due to lack of native interface for the debugger, lack of APIs and consistent effort it takes to maintain it.

By adding native debugger interface to Sublime Text we are effectively countering the main reason why people moving away from Sublime. And by supporting DAP (and LSP!) we are ensuring automatic support for new and existing languages while consolidating community efforts in the meantime!

Do we even need a debugger? Sublime Text is a text editor, not an IDE.

There is definitely a spectrum between a text editor and a full-blown IDE with Sublime heavily leaning towards the former. However, I’d argue unlike other traditional IDE features like VCS and terminal integration, native debugger interface is a natural fit for the Sublime Text. You already have all of your project files opened in Sublime, it’s just wasteful from the usability point of view to use a completely different environment for debugging the same project files which usually presented there in the same way as Sublime presents them. Compared this to Git integration, which requires a completely different representation of the same files, or terminal which literally just a terminal emulator inside a text editor window and doesn’t really benefit of inclusion in a text editor.

JSON API

Yes, that would be the most logical next step. Although Python API provides some benefits, it greatly limits the number of potential contributors and languages you can use to extend Sublime Text functionality. Every language has JSON serializer and usually, it’s fast enough not to worry about the overhead it’s creating.

Transparency

This is a very very important point. Besides adding those features I’ve just mentioned, Sublime Text team needs to be more transparent about the development of the app. We need roadmaps and updates, we need to know what’s coming next and rough expectation when. I cannot stress enough how important this is. The community needs to know what’s going on and frankly, it needs a boost of morale. People need to be sure that we are on the same page with developers.

I hope the future of Sublime Text and its community is bright and exciting.

[karolyi]

Maybe you didn’t get the memo from the other topic:

Sublime is not trying to be the all-in-one editor. There are plenty of plugins for it, or you can write your own if you want it to be that.

The main reason I use Sublime, and why it’s this fast, is that it’s not bloated with all kinds of builtins.

[schrodinger_cat]

Thanks, I’ve read the memo you linking and not argue for Sublime to be IDE-like except adding native debugger interface which is not possible to do using plugins as of now:

Do we even need a debugger? Sublime Text is a text editor, not an IDE.

There is definitely a spectrum between a text editor and a full-blown IDE with Sublime heavily leaning towards the former. However, I’d argue unlike other traditional IDE features like VCS and terminal integration, native debugger interface is a natural fit for the Sublime Text. You already have all of your project files opened in Sublime, it’s just wasteful from the usability point of view to use a completely different environment for debugging the same project files which usually presented there in the same way as Sublime presents them. Compared this to Git integration, which requires a completely different representation of the same files, or terminal which literally just a terminal emulator inside a text editor window.

Besides, that’s not the whole point, I’m trying to make.

Firstly, adding debugger interface is not gonna make Sublime Text bloated and slow (especially since it’s written in C++), you’re free not to use it if you don’t want to, however, its addition would be extremely helpful for users who need it (and judging by massive user exodus, there are a lot of such users).

Secondly, I don’t propose to implement debugging for every language from scratch just to implement proper interface and API for it, there is an opportunity to go for a standardized solution for language support. Which would help immensely both the core Sublime Text team by offloading new language support and updating support for the already presented languaged to the community using DAP and LSP and users since we’d get essentially free support for a variety of languages. That’s a win-win situation which combined with Sublime Text already solid core would result in a better and more sustainable product.

[karolyi]

adding debugger interface is not gonna make Sublime Text bloated and slow, you’re free not to use it if you don’t want to

Wrong. Bloated means it’s a part of it even if you don’t want it to be. You can choose not to use it, but it would be still a part of Sublime. This is what I’m trying to avoid, because such a thing comes always at the cost of speed. I’m always for making Sublime extendable with plugins, and against having code built in that will eventually make it slower/more bloated.

Secondly, there is an opportunity to go for a standardized solution for language support.

You are knocking on open doors. Just two examples I use: tern for Javascript, and Anaconda for Python. Both are pretty extensive/effective acting as a language extension. I don’t care what underlying protocol they use, as long as they do their job.

[schrodinger_cat]

Wrong. Bloated means it’s a part of it even if you don’t want it to be. You can choose not to use it, but it would be still a part of Sublime. This is what I’m trying to avoid, because such a thing comes always at the cost of speed.

Bloated means slow and unnecessary big. Addition of debugger interface and API isn’t gonna make Sublime any slower or bigger to any noticeable degree, it’s a relatively small addition to make Sublime more extendable.

I’m always for making Sublime extendable with plugins, and against having code built in that will eventually make it slower/more bloated.

But that’s exactly what I’m proposing to do. The point is to support standard protocols making Sublime more extendable and allowing to add more functionality for users who wish so without bloating the core.

You are knocking on open doors. Just two examples I use: tern for Javascript, and Anaconda for Python. Both are pretty extensive/effective acting as a language extension.

I don’t entirely get what point you’re trying to make. JS and Python are working. So what? There are tons of languages that don’t enjoy such level of support, unfortunately. In the meantime, there are LSP implementations for them with completions support and other features already present. And it’s not even touching debugging support. I, for example, need to debug both remote Node.js instance and Vue.js instance running in Chrome. Making plugin for that for Sublime Text isn’t possible now due to lack of appropriate APIs and native debugger interface.

I don’t care what underlying protocol they use, as long as they do their job.

Maybe solely as a user, you don’t care, but I, as someone who wants to develop plugins for Sublime and contribute to the community, do, since there is a substantial amount of difference between work that needs to be done provided we have LSP/DAP support and provided we don’t.

[karolyi]

But that’s exactly what I’m proposing to do. The point is to support standard protocols making Sublime more extendable and allowing to add more functionality for users who wish so without bloating the core.

You can start developing a plugin for that right now as we speak, without having Sublime to add anything. If you want to have this and that added to it, that’s when it gets bloated.

Addition of debugger interface and API isn’t gonna make Sublime any slower or bigger …

… and allowing to add more functionality for users who wish so without bloating the core.

Realize what you just wrote? This pretty much seems to me that you want to add something to the core, thus making it bloated. What seems to be a “small addition” first, has a tendency to become exactly that bloated stuff over time.

there are LSP implementations for them with completions support and other features already present

What stops you from creating an LSP plugin then? The UI support is already there in Sublime. Need proof? Anaconda/Tern.

And it’s not even touching debugging support.

I’m against building a debugger out of Sublime. For the reasons, see above. I use the countless language-specific console/UI debugger tools if I need to, instead of using a generalized one, that lacks features because of said generalizedness.

All in all, please don’t create a VSCode-like slow monstrosity out of Sublime. We love it the way it is.

[predragnikolic]

For me bloat also means it’s a part of it even if you don’t want it to be
I know you(@schrodinger_cat) have the best attentions with this thread, but know that there will always be people that want a feature and people that don’t want it.

I was at a meetup about VS Code…
The speaker was Isidor Nikolic (great guy). He is one of 20 Micorsoft employees that work on VS Code. He talked about their workflow of maintain the project, the problems they face…

I think the best thing that he said is that they don’t add all the features that people request in VS Code, instead they ask this question… Should this feature be built in the editor or it can be implemented as a plugin?
~ And most of the time, they concluded, that particular feature should be implemented as a plugin.

That said, I don’t expect DAP or LSP to be built in the editor itself. Instead I would like them to be implemented as plugins. One big advantage to that is that you can contribute to them (if they are open source)

[schrodinger_cat]

That said, I don’t expect DAP or LSP to be built in the editor itself. Instead I would like them to be implemented as plugins.

That would be the other way around, yeah, but we still can’t make a plugin with DAP bridge since Sublime Text doesn’t allow interface manipulations on the required level via API. And frankly I’m not sure it should, it’s too generic and unnecessary complex, that’s why I’d prefer native debugger interface and more specific debugging API for that interface. My main reason in favor of including DAP and LSP in the core is that they seem to be on the way to become ubiquitous and therefore essential in the future, and it’s better to jump on that bandwagon sooner rather than later (from a perspective of Sublime devs).

[Kili]

That would be the other way around, yeah, but we still can’t make a plugin with DAP bridge since Sublime Text doesn’t allow interface manipulations on the required level via API.

I have to disagree. I think the WIP DAP plugin does a great job interface wise.

[schrodinger_cat]

You can start developing a plugin for that right now as we speak, without having Sublime to add anything. If you want to have this and that added to it, that’s when it gets bloated.

For LSP bridge — yes, but I mostly care about debugging and keep mentioning LSP since LSP and DAP kinda go hand in hand and very similar in nature. Also, adding LSP support is just a sensible thing to do moving forward giving its popularity. When it comes to debugging, unfortunately, Sublime Text lacks APIs to implement it via a plugin.

Realize what you just wrote? This pretty much seems to me that you want to add something to the core, thus making it bloated. What seems to be a “small addition” first, has a tendency to become exactly that bloated stuff over time.

Implementing native LSP support actually should make the core smaller, in the long run, I mean, that’s an entire reason it exists in the first place — to make editor architecture more modular and reusable.

I’m against building a debugger out of Sublime. For the reasons, see above. I use the countless language-specific console/UI debugger tools if I need to, instead of using a generalized one, that lacks features because of said generalizedness.

I’m pretty sure debugger interface can be easily generalized (VS Code did it just fine) and actual implementation is offloaded to DAP.

All in all, please don’t create a VSCode-like slow monstrosity out of Sublime. We love it the way it is.

The main reason VS Code is slow because it’s based on the Electron, not because it’s so full feature-rich. If theoretically, Sublime Text would implement all of the features from VS Code, you’ll probably won’t even notice any difference in terms of speed compared to how fast it is now.

[schrodinger_cat]

I have to disagree. I think the WIP DAP plugin does a great job interface wise.

It’s completely broken for me interface wise (not sure why).

But as far as I can see it uses HTML to render debugger interface. I don’t think it’s reasonable to expect from plugin devs to implement such dirty (and brittle!) tricks in general and frankly, it kinda defeats the whole purpose of using Sublime in the first place (fast native interface), so at that point, I’d rather just stick to VS Code instead.

[predragnikolic]

I filled an issue.

Issue: API suggestion for setting single view tab visibility

What you can do is, I guess, upvote features you like. I am pretty sure that they keep track of what people want.

[schrodinger_cat]

Hm, would be that enough to implement good debugger interface though? What about buttons, tooltips, collapsable lists, adding breakpoints?

[FichteFoll]

But as far as I can see it uses HTML to render debugger interface. I don’t think it’s reasonable to expect from plugin devs to implement such dirty (and brittle!) tricks in general

electron wasn’t wrong about using web technology for once: Doing layouts/design with it is incredibly powerful and comparatively easy once you have the building blocks down. That’s why ST can render a specific subset of HTML and CSS in various locations, namely popups and certain inline elements called phantoms. Sure, this isn’t the most ideal way to go about it, but choosing a flexible solution allows using this “hack” for more than just a few buttons for a debugger interface.

Hm, would be that enough to implement good debugger interface though? What about buttons, tooltips, collapsable lists, adding breakpoints?

Buttons can be created through links in minihtml (either popups or phantoms). Example from GitGutter:

Tooltips, well, you see it. Callapsable lists, not as easily. I suppose you are thinking of a tree view of some sort? You could make that by indenting sublists and having ST add its own folding markers, or you could patch an interactive interface together with phantoms or minihtml. I suppose rendering everything in minihtml would become janky fast, so a mixed approach with text being rendered normally and a couple phantom elements weaved in for interactivity sounds like a good compromise.
Breakpoints can be done similar to the GitGutter popup and are easy to highlight in the editor as well.

I believe the building blocks are there at a fundamental level. Of course, it’s not a native interface and you need to resort to workaround or “best efforts” every now and then, but I believe that an interface consisting of this will definitely be functional. Once particularly problematic areas are pinned down, we can request additions to ST that make those in particular less of a hassle.

By the way, an LSP implementation already exists and has for quite a while: https://packagecontrol.io/packages/LSP

[eberkund]

I think language server protocol support is absolutely essential for Sublime to survive long term. An incredible amount of resources is being poured into language server implementations for various languages and without a way to make use of this work Sublime is going to be going forward at a huge disadvantage. I also think that this functionality is something that is important enough to be included in the core app and not delegated off to a third party plugin.

Some languages that I am familiar with: Golang, Rust, Typescript all are going all-in with the language server model and the experience is continuously improving.

[braver]

There already is an excellent LSP implementation for Sublime…

[clci]

I agree a good debugger is needed, but I wouldn’t integrate it inside Sublime Text. Just like Sublime Merge, a completely separated application is the right way to go. Why?

From my personal point of view, my personal way to think code, when I write code I just need to type text and I want the best tool to accomplish this. When I need to do “git things”, I don’t care anymore of how good my text editor is but I want the right tool to handle Git. Opening a different application, specialized to this task, is perfectly fine.
Likewise, when I need a debugger I change my mindset from “write code” to “wtf is happening in my program” and moving to a competely different application is, again, perfectly fine.
To say this in another way: I write code, I debug, I resolve conficts but I do only one of these at a time.

I have my own experience about writing software and, if I put myself in the editor / debugger / git-interface authors’ shoes, I think a total separation of these functionalities is also beneficial for their development. You can do the best possible choices regarding the internal structure of a single combined application like and IDE, but there’s no way the debugger part of the codebase doesn’t act as “noise” when a devepoer is trying to modify the editor part, and viceversa. To me, there’s no benefit to have them in single tool; moreover, having them separated lets me to CHOOSE what editor, git interface, debugger to use.

I didn’t know about a standard protocol for debuggers. I really like the idea. There will be a Sublime Debug in the future that uses DAP?

[dewm_solo]

From my personal point of view, my personal way to think code, when I write code I just need to type text and I want the best tool to accomplish this. When I need to do “git things”, I don’t care anymore of how good my text editor is but I want the right tool to handle Git. Opening a different application, specialized to this task, is perfectly fine.
Likewise, when I need a debugger…

I couldn’t agree more. I moved away from IDEs because I wanted to use simple, efficient, lean tools that were extremely good at what they were meant to do. The UNIX way of one app do one thing, one thing only and be good at it, is the best way for me.

People have this odd, for me anyways, way of wanting an editor, like VSCode these days, and turn it into a mini IDE with a slew of functionalities that other tools can do better. If you want an IDE, then you should use an IDE. There is nothing wrong with IDEs if that’s what you like. It is all a matter of preference and workflow in the end. If you are comfortable with an IDE and feel like it makes you efficient and productive, then by all means use one.

I love Sublime for its elegant and efficient way of letting me write code while being extremely fast and easy on resources. (Yes my PC has a massive amount of RAM, but the simple idea of a text editor consuming upwards of 4Gb is preposterous in my mind.)

I didn’t know about a standard protocol for debuggers. I really like the idea. There will be a Sublime Debug in the future that uses DAP?

Editor wise I am a Sublime Text and sometimes vim (mostly when remoting), guy. Although I understand some of the appeal and can see why some people enjoy having a tool like Sublime Merge, I am a command line kind of guy and am very comfortable using the git command line alone. I could see the Sublime Debug idea getting some traction the same as the Sublime Merge thing, but again for me a debugger that would supposedly be good at a bunch of different languages is not something a believe much at this point. I like my tools to be specific and dedicated to one thing. GDB for C/C++ for example. Although the DAP protocol like the LSP one is something that allows a single tool to be good in many instances so I will gladly wait and be ready to try it first hand when it happens.

[clci]

debugger that would supposedly be good at a bunch of different languages is not something a believe

I agree that a single debugger for many languages couldn’t be good, but I think that a standard protocol should allow an interchangable debugger behind a single user interface: you choose the interface you like (that should be in my mind the role of an hypothetical Sublime Debug) and then drive the debugger dedicated to that specific language through a standard protocol.

[crazyh]

people moving away from Sublime.

Really? The latest two years I was trying to move away from ST because realized that “ST is dying”. I tried Atom, returned to Vim and Gedit, even tried the hyped Microsoft’s editor but finally, I installed ST. Again… Like the prodigal son. Just wait some time: maybe people will migrate back too. The fast general purpose extendable editors still rock for everyday use.

Let each task have its own tool. VS Code is cool but it is not a fast general purpose editor…