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.
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.
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).
@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:
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.
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
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.
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.
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.
Hi @cruzd, I am sorry to hear about the problems you got with Sublime Text. I liked your post very much because it was well written, very big and well detailed. Most posts usually are very small and take no more and a few seconds to read them all. But, with your post, it took me quite some time until I finished reading it. I also had re-read all my two main big posts and fixed about 30 misspellings errors I had found. Sorry for trouble reading them. I hope I got everything fixed, except for the may be versus maybe stuff. I just did not get whether I should use one or the other, then, I just used may be everywhere.
Here, I present some interesting facts I just had researched. I just looked in the VSCode repository, and its first commit was by @Erich Gamma in Nov 13, 2015 (He is one of the members of the GOF, or The āGang of Fourā, authors of the famous Design Patterns book) and as of right now VSCode has 44,886 commits with 803 contributors.
And Atom first commit was by @Chris Wanstrath in Aug 19, 2011 (He is the co-founder GitHub) and as of right now Atom has 35,947 commits with 427 contributors.
While Sublime Text first public release was in Jan 18, 2008, guess by who? @Arnold Schwarzenegger, of course. (I am just kidding, @Jon Skinner) and has an unknown number of commits with a unknown number of contributors (May be 3, Jon Himself, Will, and Dylan Johnston). Accorddly to Sublime Text blog, I calculate the initial commit for Sublime Tex was around Nov 12, 2005
November 12, 2007 by Jon Skinner
Hello! New beginnings are fantastic. This one especially, because itās a beautiful spring Monday, and I didnāt wake up to an alarm this morning. Today is my first day working full time on my own software project, without a paycheque parachute.
Itās almost two years since I wrote the first line of code for this project. I think itās still in there somewhere. After spending so much spare time on the project, it builds up a momentum of its own, culminating to an inevitable mass. Which is why Iām sitting here at home, switching between writing this post and staring at source code, and not pushing bits at the day job.
Personally, I love reading about software startups, and if you do too, dear reader, then you may want to continue reading.
Thanks @addons_zz for this great āreviewā. This topic absolutely concerns me and Iām curious what the future bringsā¦
I already saw that many ST plugin devs are moving over to VSCode and they arenāt supporting their plugins anymore. The biggest loss for me is that @ihodev isnāt supporting his great theme Boxy/DA UI anymore. He even deleted the repositories on github, as you can read here:
Recently i started to develop my python scripts in VSCode and how should i sayā¦ You can feel, that there is a quantum leap regarding python development (because of the debugging features).
For C/C++ i still use ST, because we develop code for embedded systems and there you canāt use a step debugger. ST combined with EasyClangComplete and CTags is really valuberably in this case.
Anyway, VSCode supports this by default with IntellliSense and itās working great.
This makes it really hard for me, because i am an inveterated user of ST.
I really would love to hear an official statement from the ST devs, how they deal with this topic.
The thing is: As you said @addons_zz, sooner or later, this topic will result in a big impact on ST.
Either ST will become open source or the devs are zealously implementing something attractive (not to forget the bugs to fix)
The Meetio Theme makes use of some of them already.
As a result theme customization (fonts, colors, tab-sizes, ā¦) can be reduced to āchanging some settingsā in the future, without bloating a theme with dozens of unused hidden entities, which saves a lot of RAM.
No more custom theme settings need to be placed in the Preferences.sublime-settings. They are just defined in the variables section of a theme.
In the end you just need to create a User/<name>.sublime-theme file with a variable section, to customize an installed theme.
Since I was āinvitedā by @addons_zz to give my own two cents (from another thread). Iāll try to be quick.
Iām new at software development. Was turned on to ST by a friend (who, ironically, has since switched to VSCode). In the meanwhile Iāve bought the licence and have enjoyed working with ST quite a bit. But:
ā I think the ST documentation is appalling; it seems to be a piecemeal mess of official and unofficial documentation, and the official docs are poorly written and incomplete. Honestly I found this state of affairs a bit shocking, because having good docs seems the least amount of politeness / professionalism that should be extended to package developers. I donāt know what happened here, but it gave me the impression that the ST team somehow felt and some-point-in-time-or-other that ST had reached such rock star status that they didnāt need to write good docs anymore, that their groupies would do it for them. This is kind of a turn off for me
ā Secondly it may be a small thing, but I was discouraged by this core issue from 2015, still open:
Some people (like me) donāt like blinking carets. The blinking caret stresses me out. I prefer a big fat non-blinking caret. (Big and fat so that I can see it.) But the big fat block caret hides the underlying characterā¦ because someone forgot to implement alpha channel support for said caret. And weāre stuck waiting years for them to add the alpha chanel, becauseā¦ whatever. Because it doesnāt fit into their own personal workflow, so presumably they just donāt care.
On the plus side:
ā I like the idea of supporting independent devs, so donāt mind paying for my software (especially if itās good, haha)
ā the forum is really great and the people are really friendly (thanks you-know-who)
ā at least SublimeIssues/Core keeps their old issues open instead of closing issues with āoh, we donāt care about that, sorryā, as some do
Anyway, to summarize, Iād just like it if the docs were fixed up and if the devs spent some fixed fraction of time working on the old core issues that are still open, instead of prioritizing shiny new stuff like git gutter or sublime merge, etc.
Maybe like some people said, they could hire addons_zz to do said work on coreā¦
Maybe a goal for 2019 could be to close all leftover issues from, say, 2013?
Or else the VSCode/Sublime battle might go down as just another notch in the belt of open source software.
New software isnāt around long enough to have issues as old as ST. All old software does. If issue X is important to you, that says nothing about how important or easy to fix it actually is.
Just hiring some random dude that apparently has a lot of time on his hands is not how you shrink an issue list. Setting random goals also isnāt.
Would I not like builtin Terminal Support on Sublime Text?
Would I not like git integration on Sublime Text?
Would I not like RTL language support on Sublime Text?
Would I not like countless other new coot things in Sublime Text?
Of course I would like, but I would definitely wait for all that to be implemented only after its old bugs are fixed. But what will bring more license buyers for Sublime Text? New features as RTL support, git integration and terminal integration. Then, what is more likely to happen is these new features being implemented before old bugs get fixed. As Jon said, Sublime Text is his commercial venture and for him to keep it commercial, he needs new license buyers.
For me, it was absolutely not required for Sublime Tex to add builtin git support. As an old user I am very happy with its functionally, what I am not happy is with is countless bugs, which are not fixed and are surpassed by new features implementations everyday. Of course, it is nice to have builtin git integration, but at what cost? The price we are paying is old bugs just getting older while new bugs (from the new features) just keep popping in. If old bugs where fixed before new features are implemented, I probably would have nothing to complain, but I cannot know for sure because this never happened.
I definitely do not use SublimeMerge, because since 2014, much before I started using Sublime Text, I already had been using https://www.syntevo.com/smartgit/. The advantages from SmartGit to SublimeMerge are countless. First, SmartGit has their team of developers fix bugs. And since 2014 I found countless bugs on SmartGit, and never took them more than a month to come up with a new update, either on their development build or on their stable build as a hotfix. Now, I wonder about Sublime Text which is a very small team, and now decides to launch a new product. I would be OK with that, if Sublime Text team was like SmartGit team, fixing the bugs you report on it, before adding new features.
But Sublime Text team has bugs as older as 2012 and which are not fixed yet. And they just decide to launch a new product, iā¦e, more work on their hands and more bugs for them to fix (because as long as they are implementing new features, these new features will also occasionally having new bugs for them to fix). This is more like just begging for old users to find a another editor, because they absolutely does not show any estimation whether they actually plan to fix old bugs someday. By their history, they are more likely to keep adding new features and launching new products for ever. And the old users of Sublime Text which are already using it, are doing so by living with old bugs. Most fanatic users just seem to not care anymore about old bugs, and just forget about them rooting on the issue tracker.
Adding more developers to work on the product is not how bugs are fixed? You are right, to fixing bugs, you fire developers, reducing the team size, which will inevitably end up fixing old bugs. How to fix more bugs? You reduce the issue list by fixing bugs other than adding new features first. Adding new features will inevitably create more new bugs (bugs on the new features). Bugs on the new features will have priority over old bugs on old features because new features are targeting to bring new users to Sublime Text, and if the new feature do not work correctly, no new user will come to Sublime Text.
Some new features are really comprehensive, as updating GTK 2 to GTK 3 and adding OpenGL support on Sublime Text 3.2 and 3.3 because Sublime Text does not work correctly with some video graphics boards with resolution of 8K. These ānew featuresā I would just call bug fixes, iā¦e, Sublime Text is lagging on 8K screens with some AMD Graphics boards and OpenGL support should fix this. Other new features as builtin git integration are more to bring new users other than keep old users. Sublime Text already had a third part package which did some git integration. Of course, its performance is not comparable with the new builtin one, but instead of adding this new feature, they could spend time fixing bugs from their oldest bug to the newest one.
Every release we do address old bugs/enhancement requests. Perhaps the things you want havenāt all been addressed, but I make a point of addressing a combination of old bug reports, recent bug reports, syntax definition pull requests, enhancements that help package developers, enhancements for casual end users, and more.
Feel free to go through the milestones in this dev cycles:
Either way, Iām going to continue to address bug reports, pull requests, enhancement requests and so forth, because that is part of doing a good job at building and maintaining a mature product.
In general, the best way to help provide feedback and help ensure bugs get fixed are to provide clear, simple instructions on how to reproduce and issue, and info about the scope of the issue and how it affects you. The more convoluted/subjective the issue and the longer it takes to try and reproduce or understand the specifics of the bug report, is the less time we have to work on other things.
The thing that I really appreciate about ST is the syntax engine.
Itās very easy to write a syntax for anything you want.
This may seems like a detail but Iām sure it would be a great advantage for ST over time.
For ex the Typescript syntax is really crappy in VSC
Most users donāt notice it because Microsoft invested in a full Language Server so that Goto definition works properly.
In ST there is no Typescript support by default but tweaking an existing syntax took me about 1h to get a nicer result than in VSC and with a working Goto definition.
Also VSC seems to have a lot of caveats, I was recently working on a side project in C# on Linux. I really wanted to use the VSC debugger I heard everyone raving about.
But long story short, I wasnāt able to make it work and I was back to ST.
Wrt Open Source Iām not convinced thatās really a good argument. In a project this side it takes a long time to get to know the codebase, and I donāt get paid to fix my text editor, but to write code so ĀÆ\(ć)/ĀÆ
Anyway itās 2019, I still have fun coding with Sublime after 5 years, still have fun writing plugins and syntaxes that Iām the only one to use
I was also surprised by the move to the Git integration, since my plugins where already handling this use case quite well. But it was also a common feature request. If it brings more paying users and finance ST for more years, Iām happy !
I realized I forgot to mention the command palette and the very excellent fuzzy find algorithm !
In Atom I search for āpack settā and it finds nothing because the entry is name āSettings view: view installed packagesā. While in ST āsett preā finds the entry āPreferences: Settingsā.
This was added in build 3154 so big up to new features !
BTW Iād be ready to pay to have a command line tool Ć la dmenu that behave like ST fuzzy find algorithm.
I am with you on this. Python is my prime scripting language of choice. Homebrew (the OS package manager) for the Mac uses Ruby (yuck) and that has discouraged me from pitching in on the project: fluency in ruby is very low on my list. Python is far more established, too bad they chose Ruby. then again, what if the ST chose Ruby. So maybe JS wasnāt so bad a choice after all
