Sublime is just such a great editor. I came from Vim and was so pleased to find out about it. My languages of choices are PHP and HTML/CSS/Js with VueJS, and I've tried all the major editors out there. Nothing beats Sublime performance. Moreover, while VSCode has nice enhancements, for the languages I'm working on, I don't feel it has anything to bring that would beat Sublime. Sublime is just so damn fast and has great plugins. The killer feature is the lack of battery consumption - I work mostly on battery and VSCode/Atom are just CPU drainers.
Sublime is weirdly frustrating to me. I keep wanting to switch to VSCode (and occasionally Atom), but then I keep returning to Sublime. The main reason is that on my 4+ year old laptop, the difference in memory use and speed matters enough.
I had the same experience with Firefox. I switched to it about two weeks ago and really tried, but it just 'feels' clunkier than Chrome. What frustrates me is that I can't tell if that's actually the case, or if it's just that I'm used to Chrome.
At least with Sublime the difference in performance is clear enough.
It's probably so obvious that it does not merit a formal test. Atom and Vscode run on Electron, an entire instance of the chromium browser that renders the UI in HTML and CSS and uses JS for logic. Sublime Text is a native application with a much more efficient system for rendering the UI that does not involve web technologies. Open any of these editors for yourself and note the CPU usage: it's a disparity representative of a web browser (which atom and vscode are!) versus a simple text editor.
I'd also add that VSCode and Atom don't support the conventions used in text editors on the native OS. There are several keyboard shortcuts that "just work" in Sublime Text – which I'm used to from Mac OS in general – that don't work at all in the Electron-based applications.
Sublime Text is a really nice and performant text editor, but one thing I unfortunately just can't get past is how excluding files from fuzzy-finding (Cmd+P) is handled. Files like .gitignore are not respected, so I need to kinda-replicate what is in .gitignore for every project in Sublime-specific project files. I thought I'd write a plugin for that, but it's not even possible to completely model .gitignore exclusions using Sublime's system because that's not powerful enough [1]. Lastly, excluded folders and files are removed _completely_ from the sidebar instead of, say, being greyed out like in Atom or VS Code. This means that if I do need to look into, say, a file inside node_modules/, I have to open it through other means.
Some of the changes in this build augmented the existing options for filtering files and folders. In addition to completely removing node_modules, you can cause it to be ignored from Goto Anything by marking it as "binary", or exclude it from indexing if you don't want Goto Definition and Goto References to show for that. 3.1 also adds the ability to specify all of these filtering options per-folder. See https://www.sublimetext.com/docs/3/projects.html for the details.
My plan is to get .gitignore working natively in a future dev build. I have definitely heard the request from a number of users, and I can appreciate why people would want that option.
To balance out the negativity: I absolutely love sublime text. It runs beautifully on my 7 year old laptop, unlike other newer text editors that don't care as much about performance.
I tried to go back to Sublime when I started doing Elixir development. Did the rounds: Atom, VSCode, IntelliJIdea. They were all frustrating to me.
I finally took the time to properly setup neovim, and switched to VimR. I was using vim bindings in all of the above anyway, so what was the point if trying to make these CPU-heavy beasts something they were not?
They all take a lot of work to setup correctly if you are using anything outside the norm. Yeah, getting neovim to that point was more work, but not that much more. And it's fast, and the damn bindings always work because they aren't bindings.
It looks like I'm supposed to use embed for syntax scopes like p-lang highlights, but the docs don't really provide a good example of how it's meant to be used.
So embed is designed for embedding one syntax within another. Such as the script tag in HTML, or fenced code blocks in Markdown. Previously to embed another language, you would have to use a with_prototype that would prepend a pop pattern to escape the nested contexts once you reached the end marker, whether is be a close script tag or three backticks. Typically this would be a lookahead that would pop.
However, when using with_prototype, you are create a complete transitive set of new contexts that all include the prepended match rules. This also means that new regex patterns have to be compiled for each of those contexts. This leads to higher memory usage, potentially in multiple places. For instance, the HTML syntax can have CSS embedded in a style tag, or a style attribute, both with different end markers. So two complete sets of the CSS syntax had to be copied into the HTML syntax.
With the embed action, the escape pattern is scanned for first. Once found, the embedded context is then used to highlight the text up until the escape, at which point the syntax pops any number of contexts up to where the embedding happened. This means that we don't have to compile new contexts since the escape is matched separately before the regular matching.
This, combined with optimizing our syntax definition memory layouts and de-duping our regex pattern cache is the majority of the memory savings we managed to accomplish in this dev cycle.
I had to sort of make my own. Each theme I tried had something that didn't work for me, the background was too light, or too dark, or I could barely see the text selection. So I settled on the Base16 Ocean Theme and tweaked with this web app https://tmtheme-editor.herokuapp.com/
You can try out the new Celeste Theme. I personally also like Espresso Soda and Katzenmilch for lightness.
There's also an XCodeish theme available or the Base16 ones are also great.
Yeah I've been using Hasklig for a while now, really like it.
Before that I was using Ubuntu Mono and always found it really hard to find a good font that was just the right thickness. A lot of the other ligature fonts like Fira Code just aren't right for me.
What are you using? I've always felt that Sublime Text has had a pretty decent update schedule. I like it myself, but if there are any better editors out there (besides the usual Vim, Emacs, Nano, &c...), I'd definitely appreciate a recommendation : )
VS Code here too, but, I do miss the snappiness of Sublime, e.g. in startup. VS Code feels like half an IDE in terms of startup time.
I still fire up intellij IDEA from time to time though, it's a huuuge difference. That one has noticeable typing lag and such too, very annoying :/.
If there's an IDEA developer here, please make it so that the editor and typing rendering thing is NEVER blocked by ANYTHING, EVER. I'm noticing it's trying to do some work (autocomplete? error detection?) while I type and it's causing notable delays in typing and rendering.
I never consider VS Code a text editor but a lightweight IDE, and if they marketed it as such I think it would remove the "ew whys this taking so long" mentality.
As for IDEA, what OS / hardware do you use it from? Depending on that + how it's configured are all factors. I rarely get JetBrains IDE lockups anymore (on Linux) I only ever see lockups when I'm on Windows with ReSharper + VS 2017, and yes, they do SUCK.
This is my same experience. I even install VS Code on remote machines and just use X Forwarding, works pretty well thus far.
I still keep Sublime around as my sorta notes editor where I keep opening new tabs for different things cause everytime I close it (despite not saving anything) it comes back with everything I have, then I wipe all the tabs after a while.
If ST3 had the plugin ecosystem that VS Code has I wouldn't mind using it again. I think ST3 needs to make itself have a much more powerful plugin architecture.
With VS Code I get so much out of the box, with ST3 I have to install the plugin management (I think they might of changed this to be installed by default in more recent versions idr).
To whoever works on either ST3 or VS Code: Thank you, you guys do great work!
Same here. I want to go back to Sublime but I had some serious issues getting my linting plugins to work properly, eventually I gave up and it all works out of the box with VS Code, despite it not being as fast.
Interesting you say that, in the dev shop where I work practically all the devs and ops people use sublime text as their editor of choice, I think there’s a couple that use vim.
7 months for a minor version is a long time considering VS Code has done monthly releases with huge changelogs in that period: https://code.visualstudio.com/updates
VS code has had a lot of catching up to do. I’d expect them to be shipping more changes.
The “minor version” statement is kind of strange. Would calling this 4.0 make it better?
What is Sublime text missing that’s taken too long to deliver? If it does everything you want and is actively supported/developed, the fact that they ship big version bumps infrequently shouldn’t matter.
With the wealth of high quality and extremely portable code editors out there I never understood how one could justify using a proprietary closed source editor. Want to code on NetBSD? Woops. Oh the devs moved on and do not offer support anymore, nor will they publish the source? Well better trash 10 years of scripts and muscle memory and move on to something else then. Or maybe you'd just like to be able to fork it to tweak something?
Closed source IDEs I sort of understand because they're generally tied to a certain environment and can offer functionality not easily emulated in open source offerings. For simple code editors I really don't see the point though, especially since the feature list doesn't seem to offer anything significant that's not already available (sometimes for decades) in open source alternatives. What am I missing?
Are you really dissing the tremendous efforts put forward by the Sublime Text developer?
Editors such as Visual Studio Code have largely caught up feature wise yet ST still represents something rather unique as a super fast, easily customisable and aesthetically pleasing text editor, with multi selection editing, fuzzy search command lookups and json configs - for a long time it was heads and shoulders above most others.
Now others have copied ST's main innovations, but it doesn't change the fact that Skinner got there first.
I went from Textpad straight to ST, skipping Eclipse etc as being too slow and ungainly. These days I use Visual Studio 2017 for Resharper and NCrunch, but I've still defined a macro to open for editing in ST when I just want a lot of changes done.
>Are you really dissing the tremendous efforts put forward by the Sublime Text developer?
I'm sorry if it sounded like I said anything like that, I'm talking solely from the point of view of the user, I have no doubt that a lot of work goes into it. I'm just saying that as a user I really don't see the point of taking the risk of using a closed source tool when high quality open source code editors exist.
Sublime Text is great and I don't really feel bad installing it because I have an enormous trust in the developer, but: It is proprietary, with the usual problems.
Though I also have to say that it is so complete that I have never had the wish to extend it.
Because as software developer I want the developers of my tools to be able to pay for their needs, just like I want my customers to pay for my software.
And no one can pay a mortgage or their kids school just from donations.
Yep! And as I use these quality tools to earn my own paycheck, it is certainly worth giving a tiny fraction of that to the developers both in gratitude and to ensure more is coming.
Yes, sort of. Sidekiq, for instance. The core product is free (and perfectly great), but the Pro version brings a lot of money. https://github.com/mperham/sidekiq
I’m not familiar with Sidekiq. Am I correct in assuming that the “pro” version includes functionality that is not open sourced? If so, this is an example of proprietary code supporting the author with open source providing the free foundation.
Yeah, something like RedHat does make lots of money off pure OSS because they sell huge support agreements to large orgs. It's harder/impossible to get smaller businesses to pay for smaller things like tools without holding back functionality.
It's all about incentives. If you are selling support, you are incented to give poor support and documentation to your free users. If you are selling functionality, you are incented to give good support to everyone with the understanding that they need to upgrade if they want that functionality. I think the open core model makes for a happier, healthier community in general. The line in the sand where the user needs to pay is very clear and no one is treated poorly.
It depends of your definition of can is. Of course you're allowed to do so. But for a desktop app with few moving parts (unlike an OS or complex enterprise software) there's few need of support or customisation. What business models do you have left ? (Apart from being paid for education by example) ? So if you cannot financially support it long term you effectively cannot charge it. There are few exceptions and they often rely of the capability to build but I think it's a net positive since the good ideas (multiple cursors done right) can be implemented in other editors.
I don't understand this reply, I'm not advocating pirating Sublime Text, I'm just pointing out that alternatives exist. It's not even a money problem (I've donated to support open source projects in the past) it's just that I consider my editor an extremely important tool that I've invested a lot of time learning and customizing. I've been using emacs as my main editor for about 15 years now and I can't really imagine working without it. And I don't have to, because being open source I know that it's not going to go away no matter what happens.
Your "think of the children" argument is frankly dishonest and completely besides the point. You make it sound like using open source software causes developers and their children to starve. Am I a bad person for running Linux too? Think of all these Windows devs who have to care for their sick spouses and children. That's ridiculous.
I was an active subscriber for Linux Journal between 1996 until 2004, now I am subscribing again, even though I spend 90% of my time on Windows.
During the early Linux days I have bought several Linux distributions either via Walnut Creek or directly from them.
Every time I do a Linux distribution installation at home, I do donate something to the distribution, as if I would actually be buying it.
So I do put my wallet where my mouth is.
My argument is not dishonest at all, rather from someone that came to realize there is no sustainable money flow to make from selling tools to FOSS developers, and hence why all good tools have switched to the enterprise customers.
Well, I can tell you few reasons why I am still using (and will use) Sublime:
- it is way faster to start than, for example, Visual Studio Code and I just prefer it for quick edits (at the same time it is easier to configure than gVim/Emacs and has modern UI)
- I like the way multi-select works in general and in the vintage mode specifically (I'm very productive with it)
- I use it heavily when I need to analyze source code - the indexer is fast and allows me to quickly jumps between symbols and files
It does not mean I use Sublime solely. When I need to develop some code in Python/PowerShell/Go/C#/... I switch to Visual Studio Code, where I have all the necessary plugins and debuggers. About a year ago, I turned to Sublime from gVim (which I have used for more than three years) and never looked back.
Not in the literal doesn't crash sense, but in the sense that they're less likely to be distracted by flavour-of-the-month features and have a consistent vision of what they want from an editor.
I've been using sublime for many years and I've never had to re-learn what I'm doing.
Yeah but with something like VS Code you have the best of both worlds.
You get corporate backing, they're writing it because they need a decent Microsoft/Azure stack editor available on all platforms. They're getting something out of it and are likely to be working on it for awhile. Plus with such a heavy extension focus they're unlikely to flat out ruin the core editing experience itself.
But if they did something out of left field or abandon it entirely, the community can pick it up where it is and run with it.
Even on a very capable PC Sublime Text still runs circles around Code for raw performance.
On one hand I'm glad that Code has copied most of Sublime Text's features as it makes it easier to use code for eg Typescript Dev (the out of the box experience for that is arguably better in Code), but on the other hand it does also feel like they just ripped off ST devs' work.
> Even on a very capable PC Sublime Text still runs circles around Code for raw performance.
If this were an issue in my day-to-day I wouldn't be recommending it. VS Code performance is fine, even when searching through large logfiles.
> on the other hand it does also feel like they just ripped off ST devs' work.
Are you comparing the products out of the box, or are you comparing Sublime with ton of extensions installed?
When I posted my first comment in this thread, the headline was that ligature support is finally stable. That wasn't even available in an unstable form until several months, maybe a year, after it was in VS Code.
VS Code comes with a built-in terminal, Sublime struggles to do this even with extensions.
VS Code has VCS support built-in, throw in Git Lens and Sublime plugins don't even come close.
Speaking of Git Lens, the Code Lens feature in general is really convenient for a surprising number of things. Chasing references is what it does by default but I really like having a little complexity indicator above functions.
VS Code has a builtin debugger with language plugins for all sorts of environments. One interface to learn, rather than jumping between them.
VS Code intellisense is far smarter in my experience than you can get in Sublime with any plugins. Bonus is that you get Emmet builtin, but that's available everywhere.
And don't forget that VS Code is where the language server protocol comes from, so new languages can support a variety of editors with a single server, often times written with the same codebase that compiles/interprets that language.
You can use whatever editor you want, it doesn't bother me. I like Sublime, I've purchased multiple personal licenses and don't regret the investment. But to say that VS Code is just a ripoff of Sublime is unreasonable.
I'm comparing out of the box. I didn't mean all of it was copied, but that some of the core features of Sublime were. Eg ctrl+P to get into the quick search, the multi line editing.
I use Code myself as well and it does do extensions / language support such as Typescript much, much better, but that is kind of besides my point.
I mean, Chrome Dev Tools uses that key combo as well, I wouldn't say it's ripping anyone off.
Vim and emacs, as well as other editors through the years have had multi-line editing in various ways. Sublime didn't rip them off when it did the same thing.
Editors sharing ideas is only a good thing, it's not a zero-sum game.
Portability is the last thing I care about in my text editor. I've been on the same platform for development for the last 12 years.
The same goes for being open source: I am not going to hack the editor anyway.
If the closed source editor is better for what I'm working on, I will use it. I don't work on NetBSD for example, and MacOS is giving me the best developer user experience of all the platforms I've tried.
At the end of the day, practicality trumps idealism.
All of my arguments were practical though. I use a few closed source applications when I couldn't find any open source alternative that did the job but code editing is definitely not one of them.
> With the wealth of high quality and extremely portable code editors out there... What am I missing?
I’d say you’re missing the fact that there aren’t actually that many high quality code editors out there, portable or not. Finding an editor you like is worth a fair bit.
Notepad++ is definitely an option if you're on Windows and looking for something free(it's GPL-licenced). Feature-wise it's on a par with Sublime but it has slightly less polished UX, e.g. there's no real-time regex highlighting or markdown formatting, at least not out of the box.
I use Notepad++ at work and ST3 at home, and there is no way that Notepad++ is feature-wise on par with ST. The sidebar options aren't good, no multi-select, no good way to organize projects, and it chokes on big files.
The fact that I have to click through 30 modal dialogs every time all my open files have to 'refresh' after a network hiccup is enough of a reason to curse at Notepad++.
Wow, you are getting downvoted. I 100% agree with you, though. I have seen too many proprietary text editors come and go to be able to justify building my work around a closed-source one.
My text editor is absolutely fundamental to all my work, and I spend significant effort in customizing it to my particular needs. I loathe the idea of having to re-do all this work on a different editor, once my current one is no longer supported.
But who am I kidding, I am married to Emacs anyway.
