Sublime Forum

**flying_cat** · January 15, 2019, 4:46pm

Plugins are a very part of the sublime text eco system. I have installed a dozen plugins myself. I have noticed that most plugin I installed have not been updated for more than half of year. I think it is not a good signal.

**FHTheron** · January 15, 2019, 4:52pm

Ahh the ol’ frequent updates stigma.

An old timestamp usually means “abandoned” or “no longer compatible”, but on some occasions it just means nothing has had to change yet for it to keep doing what it needs to do. That’s why I think a public piece of software should get a sub-minor version step every 6 months just to say

I’m still alive, I still remember that I made this thing, I still consider it relevant and useful and I have not added any shiny new features since the previous version.

**flying_cat** · January 15, 2019, 4:56pm

Yes, keeping plugins up to date is important. For old packages, we do not know if it can still work with the latest version of sublime text. I think an active plugin system will also draw more potential users.

**facelessuser** · January 15, 2019, 4:58pm

I don’t get this. Why does a plugin need constant updates? What happens if it is feature complete? Yeah, some plugins do fall behind a bit. Some of mine don’t need updates, and probably won’t for a long time. Some of mine could use some love, but I have a life, and kids, and other projects on top of plugin X, and no funding for any of my projects, so I get to them when I can.

**kanlukasz** · January 15, 2019, 5:17pm

I think all users have a much respect for plugin developers, especially if they doing this in private free time

The problem is not the lack of frequent updates.
If everything works and does not need any update, everything it’s ok.

The problem begin when:

documentation is incomplete or outdated, what often mislead users
we are not able to determine whether the plugin still works, or just we made mistakes in the configuration
( I’m exactly in this situation with Xdebug plugin )

**cruzd** · January 15, 2019, 5:39pm

I know there was recent outage and from that @wbond wrote

Maybe a new focus on how the package system can be revamped during the process of moving it to “a more modern approach”, could resolve a lot of these issues… some of which I think are wrongly attributed to ST.

By the “package system” I mean from the community collaboration perspective not how it works.

**addons_zz** · January 15, 2019, 5:54pm

Just crashed once again: (Sublime Text build 3184) core dump: d13e37d0-bad0-43f0-aade-9f5d27d34768.zip

I should revert to build 3176 and wait until they fix build 3184?

Searching on VSCode Issue tracker, we can also see crash reports: https://github.com/Microsoft/vscode/issues?utf8=✓&q=is%3Aissue+is%3Aopen+crash+

**Remi** · January 15, 2019, 9:25pm

Well, there are stable and development branches for a reason. Unless this was meant to be a release candidate, I’d say the software tipping over is probably not wholly unexpected?

**AmjadHD** · January 16, 2019, 11:55am

well I think ST does pretty well in comparison with other editors, in addition to being one of the fastest (or fastest ?), having a nice and clean interface, and being very customizable … recent additions to the plugin ecosystem (e.g LSP which adds IDE-like features similar to VS Code, Terminus which integrates a cross-platform terminal into ST (similar to VS Code), others are yet to be added to Package Control such as sublime_db that will add an integrated debugger which VS Code is famous by), provides a boost to the productivity of ST.
so overall ST may go head to head with VS Code in terms of features and it’s even better in terms of performance and elegance.

**iamntz** · January 16, 2019, 12:26pm

A bit offtopic:

The main difference being that on VSC you just hit that install button and you’re kind of done.

On ST is a real adventure that implies a lot of fiddling around and if you’re both lucky and skilled, you might make it work.

**AmjadHD** · January 16, 2019, 1:39pm

yes, I was going to add this exact note, I guess VSC is accessible to a wider variety of users than ST. ST demands patience and a lot of work, but it can do better if it made configurations a little easier.

**iamntz** · January 16, 2019, 1:47pm

Well, what some fail to understand is that they compare apples with eggs. You have a text editor and you have an IDE (JetBrains, VS Code and such).

They are completely different beasts, but some users expect the same functionality from both. I don’t expect such, the LPS thingy was just an example.

**addons_zz** · January 16, 2019, 1:57pm

Definitely Visual Studio Professional (or Community) are an IDE, but I do not think VSCode is an IDE. It may be sounding like an IDE through its extensions additions, but the same would apply for Sublime Text.

Comparing both wiki pages, for Sublime Text and VSCode, they both state they are the some thing:

Visual Studio Code is a source code editor https://en.wikipedia.org/wiki/Visual_Studio_Code
Sublime Text is a proprietary cross-platform source code editor https://en.wikipedia.org/wiki/Sublime_Text
Microsoft Visual Studio is an integrated development environment (IDE) https://en.wikipedia.org/wiki/Microsoft_Visual_Studio

**bempelise** · January 17, 2019, 9:00am

Maybe I missed a point but this whole comparison is done on how easily you can write plugins on an editor and the issue is that you run on bugs on both presented choices, which is expected as there is no perfect software. But this is not using the editor but rather developing/extending it.

I would rather choose my tools based on what they already provide to me and not what I can make them to be. At the end of the day, one can even write his own editor to do that very specific functionality he wants.

For the sake on my opinion between these two editors, I find that sublime text has a very clean and concise user interface and VS Code has tried to copy bits of it but still fails. I found very confusing configuring VS Code as its settings seemed to me to be inconsistent and they remind me a mash up between what Atom tried to do and sublime text. I prefer the single .json file which makes it very clear what is going on.

**stephenll** · January 17, 2019, 2:25pm

Two comments to share:

I am not a developer. VS Code looks nearly impossible for a non-developer to extend. It is very intimidating. I think there are more non-developers out there that are familiar with python then the tech stack necessary to extend VS Code. I know not everyone is going to write their own extensions and even less so for non-developers, but having Sublime Text be extendable by python keeps me here. (among many other great things about Sublime Text)
The developers I do work with often comment about VS Code. While the code is available on GitHub, I have heard them mention that compiling VS Code is proprietary. You can not create your own build. I guess having the source is helpful, but not being able to compile means you can’t fix any issues without MS accepting your code.

**acheronfail** · January 18, 2019, 7:56am

Compiling VSCode is not proprietary - all their build scripts and documentation is online in their repository: https://github.com/Microsoft/vscode/wiki/How-to-Contribute#build-and-run

In terms of bundling the code into a packaged application (.app, .exe, etc) - you can use many different ways since it’s using electron. They most likely have this setup in a CI environment and so it’s not included in the main repository.
In any case, it’s extremely simple to re-package the app once you’ve built it (following the above guide).

And all of that code and setup is licensed under the MIT license: https://github.com/Microsoft/vscode/blob/master/LICENSE.txt

**predragnikolic** · January 20, 2019, 3:20am

Why are you so pessimistic

I am just curious, what criteria must a developer tool cross to fit in the IDE world

**addons_zz** · January 27, 2019, 8:36pm

@stephenll, thanks for sharing. As already stated by someone else (@deathaxe I think) on some other post around the forum, I think Sublime Text should focus more in being extensible by its users with the Core API/Packages, other than getting out of the box with tons of builtin features. But above of all, it should never do (drugs) crash/segmentation fault. By having very nice and bug free API for Packages Developers, Sublime Text would definitely benefit more because its dedicated Package Developers would definitely feel more confident and enthusiastic about maintaining and writing new extensions for Sublime Text, instead of abandoning Sublime Text and going away for some other editor where they can do better whatever they feel like. Sublime Text dedicated Package Developers usually are always around the Forum or GitHub issue trackers helping others in fixing their problems with Sublime Text through awesome and well written Sublime Text Extensions. But most times, Packages Developers and specially new Package Developers just give up from Sublime Text and go for some other editor because they cannot stand Sublime Text API bugs limiting their creativity. But they might as well go forth and back because they cannot find another editor to stand their high imagination and creativity, and then, they become old Package Developers for Sublime Text.

There is a main difference between using a proprietary software and building it by your own. With proprietary software you can just ask, until magically they get it done for you, their client. With open source software, you can ask, until someone get it done, or you can do it by yourself.

A more serious example would be the latest development build of Sublime Text which started crashing on my computer. I can only ask for them to fix, but they can keep ignoring me for ever and never fix it because it could only affect me or a very small ground of users, but none of their other million of users. Then, how I am supposed to work with some software which can keep crashing unnoticed? This is what really gets me pissed because after spend years building extensions and settings for Sublime Text, then, just some day, for an unknown reason, I may have to stick with some old and bugged (API bugged) version of Sublime Text for ever and there is nothing I can do about it, other can may be becoming multibillionaire and trying to gently put some billions under their assets/pockets, hopefully motivating they enough to fix the crashing and API issues I am specifically having. Or unless Sublimehq hires me, but even if so, it does not mean they would let free free to fix wherever I would like to and I can just end up writing new features they would like instead of fixing bugs.

I also got to the point where I cannot improve further some of extensions/packages for Sublime Text because of bugs or limitations on the Core C++ API. Then, all I can do is wait for some future version of Sublime Text to fix the API bug or limitation. But, even if some new version fixes the API bug, how it would go about the crashing issues I am having? It may still be crashing for ever, and again I got nothing to do about it, other than ask for them to fix it and stick with an old version of Sublime Text, which does not crash. However, old versions of Sublime Text are more API bugged than the latest version. Yes, miraculously sometimes they randomly seem to be fixing some old API bug. My guess, is that when they were writing a new feature, and they noticed the bug was disturbing their new feature, then they decided to fix the bug, otherwise their thousands of new users would notice the bug and start flaming hundreds of posts like "-It is not working, help!", which is not good for sales, as they would probably not buy a license.

If I have been using VSCode from the beginning, instead of keep waiting for them to fix the crashes, the API bug or remove some API limitation, I could just it it by myself. Then, instead of spending my weekends and nights resting from my daily job, I could just spend they fixing VSCode crashes and API issues. At least, I would have an option to do something other than wait. This situation focus on how much easier is to develop Packages for Sublime Text, other than Extensions for VSCode. As you may already notice, with Sublime Text I can get much more time resting from my daily job, because I only need to wait for Sublime Text team to do something about its C++ Core API bugs and crashes/segmentation faults, while developing for VSCode, I would have no excuse to sit my ass on some corner and keep complaining about my issues not being resolved.

However, even If I had started using VSCode from the beginning, I am not sure I could get where I am here today with Sublime Text, because I do not know what kind of problems I would have to fix on VSCode. I guess I will get to know more when got the time and I start fixing the problems I already got on my todo list.

Also, I think another point should be considered. Even if VSCode is open source today, it does not mean Microsoft will keep it as open source tomorrow. Some unnoticed day, they can just came out and say that further developments of VSCode are now proprietary, i.e., VSCode will now become closed source (new versions of it), or they could stop developing it because they do not get more money to fund the project. Meaning, that further developments of the latest version available for VSCode are only now maintained by community, i.e., you and me in our free time on night and weekends. Then, instead of resting from our paying job, we can get to work even more and completely for free! Isn’t this awesome?

Currently, major contributions for VSCode seems to be from Microsoft employers (as they work full time on it). It also seems that community volunteers are well engaged as described on the following on issue. Then, I think even if Microsoft bails out from developing new open source versions of VSCode, community volunteers could keep it running smoothly. It is very important to remember that, me, only by myself, I am nothing. Only a collaborative effort from a group of people can get somewhere for some big project as a full featured text editor. Meaning that, whatever I ever had built for Sublime Text, would definitely not be possible without the help of Sublimehq (for creating Sublime Text, as we know today) and several highly active community members/contributors and countless others which are anymore part of the Sublime Text community, because they already moved on from Sublime Text to some other editor as VSCode or a JetBrains IDE or they are well satisfied with Sublime Text as it currently is and just do not do any more contributions for it.

Then, just tell your users to build it from source. Recently, to build VSCode become simpler. Originally when I started with VSCode a year and half ago, took me 2 days until get it done right.

What seems to be the problem is that, you cannot distribute the main URL channel for the "Visual Studio Code Marketplace", as described and still pending some resolution on the following issue:

I am not sure whether I can or cannot distribute binaries of VSCode. I think you could be slightly mistaken, I am not a Copyright Lawyer, but if I understand it correctly, in fact the binaries compiled and distributed by Microsoft website for VSCode are proprietary, but you should be able to build it by yourself at your home and share with others who trust you (your binaries files). At least, accordingly to VSCode license, it states:

github.com

Microsoft/vscode/blob/master/LICENSE.txt

MIT License

Copyright (c) 2015 - present Microsoft Corporation

All rights reserved.

Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation files (the "Software"), to deal
in the Software without restriction, including without limitation the rights
to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:

The above copyright notice and this permission notice shall be included in all
copies or substantial portions of the Software.

THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE
AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER

This file has been truncated. show original

After almost forgetting about it, there is also LimeText:

I love the Sublime Text editor. I have created several plugins to make it even better. One thing that scares me though is that it is not open sourced and the pace of nightly releases have recently been anything but nightly, even now that version 3 is out in Beta.

There was a period of about 6 months after the Sublime Text 2 “stable” version was released where pretty much nothing at all was communicated to the users about what to expect in the future, nor was there much support offered in the forums. People including myself were wondering if the product was dead and I personally wondered what would happen to all the bugs, crashes and annoyances that still existed in ST2. This lack of communication is a dealbreaker to me and I decided that I will not spend any more money on that product because of it.

As none of the other text editors I’ve tried come close to the love I had for Sublime Text, I decided I had to create my own.

– @quarnster

Sadly, it seems the project had dried out of contributors and no new updates have been coming recently:

I would say the LimeText project is just missing me, as I am not over there writing and doing contributions for it. That is definitely an open source project, but has no one more working much for it recently. Whether I should start focusing my time on VSCode or LimeText is an interesting question. Let me see where I am going to end up few years from now. Hopefully, Sublime Text will be able to fix all its crashing issues and eventually its Core API for plugin development (i.e., for developers use, may be me, may be you reading it) gets improved and fixed.

This is the other side of “Open Source” projects, specially big project as a full featured text editor as LimeText. While VSCode and Sublime Text have teams of programmers working on it full time, open source projects usually do not get this privilege often as VSCode does. Because everybody has to pay their bills, and they cannot work full time on something for free or no food. Sometimes, open source projects get lucky as VSCode and have some big money supporting them financially, or some full pensioned programmers start working on it because they think it is to much fun. Most successful open source projects, are usually small enough projects and one or few guys can maintain it on their free time/weekends. Other times, even if they are big projects, they can have so much contributors from everywhere on the world, and everybody small contribution sum up to a big thing. Following this line of though, I will probably end up working more with VSCode development other than LimeText.

After looking over old posts on the forum, I found the following posts to be interesting to read:

I am going to revert back to Sublime Text stable build 3176 for few months to confirm whether it is crashing or not. After confirming it, I will go back to the latest development build available.

I just researched this topic on Google and found this awesome post by @leedohm:

The term “IDE” comes from Integrated Development Environment. It is intended as a set of tools that all work together: text editor, compiler, build or make integration, debugging, etc. Virtually all IDEs are tied specifically to a language or framework or tightly collected set of languages or frameworks. Some examples: Visual Studio for .NET and other Microsoft languages, RubyMine for Ruby, IntelliJ for Java, XCode for Apple technologies.

An editor is simply that, a tool that is designed to edit text. Typically they are optimized for programming languages though many programmer’s text editors are branching out and adding features for non-programming text like Markdown or Org Mode. The key here is that text editors are designed to work with whatever language or framework you choose.

The tradeoff here is that while you can generally get off the ground faster if you’re working within the realm of a given IDE, over the long term you spend a bunch of time retraining yourself when you inevitably change from one language or toolchain to the next. If you use an editor, you can continue to use the same workflows that you always have. Tools that you’ve built into your editor can be carried over to the next language and framework. Your editor becomes more powerful and more customized to how you want to work not just over years but potentially decades. Just ask people who use vim or Emacs … both of which have been available for over 25 years!

So, if you want something that you can just jump into and be productive right away in a specific technology, perhaps an IDE is what you’re looking for. If you want a tool that you can shape and customize into exactly what you want out of it even if it costs you some time up front configuring things, then an editor is probably more your speed

https://discuss.atom.io/t/what-is-the-difference-between-an-ide-and-an-editor/32629

https://discuss.atom.io/t/eclipse-ide/32613 eclipse vs atom IDE. what are the differences?

This cited post by @leedohm wonderfully put into words and explains the difference and why I love and use Sublime Text instead of IDEs, but also explains why Sublime Text gets on my nerves when I constantly hit its limitations or problems directly coming from the C++ Core code, which is currently out of my control.

I think I am actually just sad because I love Sublime Text so much, and there is nothing I can do to fix new crashing bugs or a few bad old API bugs which are just getting older each day, instead of being fixed.

**iamntz** · January 20, 2019, 5:44pm

Although we risk detouring the original post further more, an IDE is something that is also and editor. Not the other way around.

I.e. you have an Integrated Environment to do your job. This mean code tools (refactor, linting, autocomplete), debug integration, build tools and such. In my books, and IDE is a tool that will make you leave your editor as little as possible.

VSC despite of their claims, it is an IDE out of the box for JS/TS at least. Then is very easy to make it play nice with PHP, for example. (very easy as in click, click, done).

Now, compare with Sublime, which is a text/code editor: apart of syntax highlight, you don’t have support for any particular language. You need an autocomplete (a la Intellisense)? Good luck. You want a debugger? Ha! Prepare for some arcane stuff.

And so on.

Again, I’m happy with what I have in Sublime, I only have a problem with this disproportionated comparision, of VSC vs ST.

**cruzd** · January 20, 2019, 11:47pm

The Fresh Perspective

I’m weighing in one more time from the view of someone who’s motivation coming here was to solve a requirement and to maybe, contribute if I had success with it. Loyalties aside, what should be considered are a few basic things about any tool you use for productivity with regard to the role it plays in your tool set. I will demonstrate this simply with examples that were outside of the subject I originally posted about which dealt with “getting up to speed” on developing for ST3.

If a particular feature of a tool limits ( or could potentially increase ) your productivity you can:

search and find out if someone has solved for your requirement ( this is where I was inspired to contribute )
fix it if it’s not too difficult ( this is where I began to dig in a little )
dig deeper if it’s important enough ( this is when I realized that there was only so much a contributor could do )
join others who have asked for a solution and wait for someone to fix it ( now I’m beginning to question if I have the right tool )
pay for someone to fix it ( if the fix is too involved this option becomes prohibitive )
reluctantly, find another tool that may solve your requirement. (?)

My Experience with ST3 to fill some some requirements

Requirement: Drag and Drop folders for SideBar package
Outcome: Once I searched the forum and stackoverflow it became apparent that this functionality was desired by many, looked at by people far more experienced than me and still not implemented despite requests dating back to 2011. I was not going to be able to fix it but maybe I could find a work around to make it a little easier. I started to look at key bindings so that maybe I could at least have keyboard cut/paste functionality instead of using the context menu to save a step. There were no key bindings in the package settings and after a few cursory internet searches and inspecting the code a bit it just got to be too much and I conceded to the fact that this was not going to happen. Still, I was willing to overlook that.

Requirement: Contextual folder customization
Outcome: After trying to find a way to use the OS icons instead of the ones provided by the Side Bar Enhancements package, I didn’t think it would be that difficult to assign custom folder icons based on a given folder name such as “Admin” or “Archive”. When I determined that it wasn’t a frequently requested feature, I though to ask the question in the forum before jumping in which went unanswered as some do and is not a big deal. I went through the documentation, tried many ways to figure this out myself an saw no way that I could do it.

Requirement: Custom Syntax
Outcome: I say custom syntax but really I just want to be able to save a file as *.whateveriwant and use an existing syntax for it. I did not see any way to do this other than duplicating another syntax and customizing it to recognize your custom file extension. If I wanted to change that, it seems that I’d have to create a unique syntax file for every variation I wanted to apply. That leaves me with the impression that functionality to associate syntax with a custom extension would require it to be done at the core level. Not good news for me, especially if it takes so much time to implement much more requested fixes/features.

###My Experience with VS Code to fill the same requirements.
Requirement: Drag and Drop folders for SideBar package
Outcome: Out of the box functionality nothing to do

Requirement: Contextual folder customization
Outcome: Installed an Icon theme and customized it to my needs by making edits to the theme’s .json file.

Requirement: Custom Syntax
Outcome: Out of the box functionality in the form of an option to configure the file association if you click on the language switcher in the lower right.

Summary

I spent an embarrassingly considerable amount of time attempting to make these requirements happen in ST3. As stated previously, I should be MORE productive by using ST and need to question whether or not what I’m expecting from a tool like ST is reasonable. Distinctions between what makes ST or any other software an IDE or an Editor can only be supported to the extent that someone can point to a source that defines it one way or another and doesn’t really make it a fact one way or another. Too much focus on the details sometimes blurs the bigger picture.

While I appreciate the minimalist approach that core ST is known for, it looks like the competitors have recognized and taken market share by addressing core extensiblity as a feature. I can’t underestimate how important that is! I had zero experience with VS Code and no knowledge of any of its features before last night and after I gave up trying to meet the aforementioned requirements in ST. In contrast, it took me only a couple of hours to install and meet the same requirements in VS Code.

Granted, the problems I incurred are not all related to the ST3 core editor. Two specifically were related to the Side Bar Enhancements package. In my opinion, that package in particular should be a part of the Sublime Text core because of it’s relative importance to the software. Evident by the fact that practically every thing I’ve come across regarding must have packages includes “Side Bar Enhancements” at the top of the list. In fact, by just including a menu tree implementation in the core design of the software without even installing the sidebar enhancement package, it naturally implies certain expected behaviors. My opinions aside, what IS important to understand here is that from these first interactions in attempting to get more acquainted with the tool, I ( as a potential contributor ) am left with little to no incentive to contribute.

Ultimately, Sublime Text is a business that provides a living for people who work in it full time so I can understand trying to protect the nature of how it is monetized. What I find unique and awesome is how software developers ( which I am not ) often give of their time ( at their own expense ) to promote, support and create for software that they don’t share the profits of. On the other end, you have those who demand and inflame with no intention of contributing or even purchasing the software. As an outsider looking in, I can’t help but to think that the main issues ( that I see ) are two fold which are kind of inter related in that by solving the one you contribute to the other’s solution.

Raising the bar on what is considered core functionality.
Enabling developers to contribute to ST core somehow.

Maybe Sublime HQ could invent a new software monetization and source protection model that will enable these things to happen!

Of course, I’m sure that it’s not as easy as it sounds. However, if should be safe to say that adaptation is a part of survival. Perhaps my contribution to ST is just to offer this insight which I sincerely hope helps.

Sublime Text versus Visual Studio Code in 2019

The Fresh Perspective

My Experience with ST3 to fill some some requirements

Summary