While mostly using Jetbrains or Atom with VIM plugin for development these days I still value Sublime for being able to handle really big files a million times better than Java/Web based editors.
I too bought a license when I entered industry and the asking price went from 20 hours of yardwork to 2 hours of doing what TextMate had helped me learn to love.
These days I mostly use Jetbrains and Sublime, but I'll never forget how easy and powerful TextMate templates were. Two steps forward, one step back.
I did spend a lot of time with Vim but never got to the point where I had all my plugin issues solved. Eventually I moved mostly back to Sublime with Vim emulation, and very recently have moved again to VS Code with Vim emulation, and I'm quite happy.
Long time "lightweight" VIM user with gvim, using tabs, and often two windows (sessions)...
On OS X, MacVim was a delight.
Since I had to swiych back to Windows, and I use VirtualBox, gvim is really slow. It also has some nasty rendering issues due to its underlying gtk framework intercaction with the Virtual Box Guest Additions. The only work around I found was some obscure tweaks in the Compiz Comfing Settings Manager (CCSM) related to screen redraws. Spent hours and hours installing different VMs, Linux Mint, Ubuntu, etc. and trying to isolate the problem in Virtual Box.
Finally recently I heard about Sublime Text... it runs SO MUCH BETTER than gvim in a Ubuntu VM.
And.. icing on the cake... I discover it has a "vintage" mode that covers pretty much everything I used (ci" to replace inside strings, dt; to "delete till ;", vit to select visual inside tag, etc. It seems to support a lot more than the documentation says.
To top it off it appears to be very configurable as well.
All in all I genuinely wonder why you'd not want to use the editor? Because it's paid? It doesn't even enforce you to buy the software, which is prety gracious of the developer.
But honestly.. what started getting on my nerves.. is whenever I'd visit discussions about vim and you always have the same clique who point out how using the mouse is "inefficient" and how using vim inside terminal is the only true way of using vim, and how using tabs is "slow" compared to their way of switching buffers, etc. I suppose you can gleefully ignore these comments but it makes you question in the end if you are using an editor out of ideology. If I stick to Sublime Text I will definitely not miss those inane topics.
The main thing I don't like in Sublime Text so far are:
- the search replace UI... I much preferred the %s// way of doing things.
( but for multi file refactoring I much prefer a special tool for that like "regexxer" )
.. So TLDR I find out half the time I try to complete something I end up spending more time undoing the clusterfuck and it makes me wonder why I use it at all. I wish devs understood the 80/20 rule and make the completion work for the 80% case, so that the editor actually serves the user instead of slowing you down. How the heck do you remember everything that can be completed? THere is simply too many possibilities so you never know quite what will happen.
.. So now I need to find the setting in Sublime to auto complete only what is in all my open files and nothing else, and it's probably much more meaningful that way. Since when you add to a project, you'll end up reusing a lot of the functions both self made, and those often used from an API.
That's my rant for the day =)
But seriously Sublime + Vintage mode maeks it easy to switch from vim if necessary. The settings are:
// (dont ignore "Vintage"
that would be the AllAutocomplete plugin, it does exactly that :) afaik it's the only autocompletion I use, for pretty much the reasons you said.
Aside from that: I love vim and use it any time I work remotely (via ssh). But I spend good chunks of my time in Linux (Mint), Windows, and Mac. And Vim is great for the first and the last, but is awkward for Windows. And even if I don't mind the gui that looks like it came out of a dog's derriere, it makes synchronizing my settings a pain in the same region just because I need to change filenames (.vimrc becomes _vimrc, if memory serves), add a bunch of conditionals to handle different features, and possibly also change line endings (I forget if that is needed). Whereas atom is easily synced with a single mostly automated plugin that pushes everything I need to a gist.
I still prefer vim on my primary work station, but I am also eagerly following atom development in the hopes of filetype specific tab/indent/linelength rules to be better supported and various improvements to performance.
And on a less usability note: Atom looks REALLY good when you are doing a code demo or a presentation.
Those who are interested in text editor design may find this series and the links therein useful:
I suspect that Sublime Text either doesn't use a piece table, or uses one that only breaks pieces at line boundaries. The reason being that the highlighting relies on running regexes on one line at a time, and it uses oniguruma for this sometimes, and oniguruma requires the entire haystack to be in one array. However, Sublime doesn't highlight super long lines because it would be too slow, so it could break its piece table on incredibly long lines so that editing them could still be fast.
I was also looking for fancy rendering and highlighting tricks, but couldn't decipher any.
Yep, that's kind of the way it works, when you start out. Then you get used to some of the patterns that the compiler uses, and you can get through several in a day, if you're lucky!
For now, Sublime's plugin ecosystem is still better. And Sublime has more polish on a ton of little things.
It will never catch up to Sublime on performance though. Not only because it is written in JS but also because a ton of the work that went into Sublime was writing custom systems for fast text editing.
Why couldn't the creators of VSCode and the open source community catch up to Sublime's systems for fast text editing -- especially considering Sublime was written by a single developer who seems to not work continuously on the project.
The JS issue is another story.
For other things (like a very nice minimap that actually renders based on the shape of characters) you are limited by what the DOM is capable of in terms of custom rendering. You can get around this by doing what https://www.figma.com/ does and rendering everything with WebGL from asm.js, but that would be a total rewrite and you lose all advantages of using Electron and you might as well just use C++ and OpenGL directly, and at that point you are just cloning Sublime.
Also Jon Skinner is a performance-obsessed wizard who does things like write a custom regex engine just to make the fastest syntax highlighting engine even faster. Whereas the VSCode team is the kind of team that wrote a text editor in JS. I will hand it to them that they did pretty well at optimizing and VSCode is the fastest JS-based text editor, but they don't seem to have the kind of performance-at-all-costs approach it would take to match Sublime.
It's not so much that it's impossible, just that I'd bet at high confidence that VSCode will never match or exceed Sublime's performance on most text editor operations.
Maybe it isn't as 'technically good', but it does the job and imo looks good. 3M+ downloads.
As for V8 it gets faster but is still far from C++. The main issue being it's impossible to make memory-efficient data structures, which are super important for editing large files.
The minimap could be on par with sublimes, but for whatever reason the dev who made the plugin hasn't made it so. That doesn't mean that it's impossible or impractical due to some restriction of atom itself.
on performance, they aren't even in the same league.
As for performance. When I need to open large log files, I still go for sublime text. If some core parts of sublime were open sourced, it would be a huge.
For example Sublime's fuzzy finder previews files behind it as you type, VSCode/Atom/Emacs can't load files fast enough to do that.
Sublime's minimap beautifully renders each character in the correct shape (at small size) using the same renderer as the main body. The DOM memory usage and thrashing when you type an unclosed quote and the whole file gets re-highlighted would kill Atom/VSCode if it did that.
Also the little things just have far lower latency. Opening a file, typing in the fuzzy finding window in a large project, deleting a closing quote that re-highlights the rest of the file, etc...
How to disable telemetry reporting
VS Code collects usage data and sends it to Microsoft to help improve our products and services. Read our privacy statement to learn more.
If you don’t wish to send usage data to Microsoft, you can set the telemetry.enableTelemetry setting to false.
From File > Preferences > User Settings, add the following option to disable telemetry reporting:
I've only seen Electron-based editors doing metrics, perhaps web developers are less offended by the idea thanks to pervasive usage of things like Google Analytics.
Collecting call stacks from crashing threads or executables can be incredibly useful for fixing them.
Measuring what functionality gets used and what not can help direct feature development (should that checkbox be as visible as it is?)
Collecting statistics on Unicode code point usage may direct development of core data structures (UTF-16 might be the best choice for the basic character unit)
Collecting CPU/memory/disk stats similarly may direct development (if most of your users have gigabytes of free RAM, that change that takes 20% more memory but speeds up things may be useful; if they have plenty of idling CPU! But no memory, things are different)
Knowing what percentage of your users run on a 80386 may help making the decision to compile for at least a 80486.
Knowing internet connection speed and amount of free disk space may help make the decision to move all help online.
Knowing the default browser can help direct testing of the help system, if that system uses the default browser.
Knowing the locale of your users may give hints as to what spell checking languages or UI translations to support.
Having access to the custom dictionaries of all your users may be helpful in improving the ones you ship with the editor.
Having access to every edit made (we are deeply into 'extremely privacy invading' territory now) may also be helpful. For example, you may discover that most of your users don't seem to know about a shortcut that combines five other actions.
Telemetry doesn't bring anything more to the table. When I see an app with telemtry, I am just thinking they don't know what they are doing.
Here is an example: https://github.com/Microsoft/vscode/issues/707
Bold move, Cotton.
Most of analytics data never gets looked at and never provides any useful insight because it's setup poorly.
Whether you should care comes down to your ideology. My view: I totally see the value in tracking your users, but I also believe there should always be an option to opt out. Tracking becomes insidious when you lose the right to not participate.
By choosing to opt out, you're showing Microsoft that there are people that genuinely care about being able to not be tracked, making it more likely for them to keep this option for the future.
How is Microsoft supposed to know you disabled telemetry? VSCode can't tell them you did, that would be a form of telemetry :P
Mostly I use it for quick renaming of variables, string fixes, and some structural changes in code.
 - multiple cursors, at least in Emacs, can work off-screen too, but I don't like not seeing what's going on when I do changes.
However, I do like to point out that it's really just eye-candy for stuff I was already able to do in emacs. Previously, I would have used either keyboard macros or query-replace-regexp to do the same things.
Ctrl-F <search query> SelectAll <edit with multiple cursors>
Do it all the time.
I tried VSCode only to find it is hardcoded to only support 3 panes at once. I often have 5-7 panes open.
It was also not clear how much work it would be to add modal selection. I tried the most popular vim emu looking for an example on how to do it only to find that feature has not been emulated yet.
I switched to vscode from sublime recently, because it has much better autocompletion and "goto definition" especially when working with JS and TypeScript code, which is exactly what I need.
Other than that I was able to replicate all features from Sublime (e.g. multipoint editing) and I'm not aware of any missing feature from what I used in Sublime. One con is that vscode is slower to start and slower to open up a file.
Have you not answered your own question?
But if your workflow ain't broke, don't fix it, right?
What a cool exercise in general.
What I really want is to make ST3 sidebar menu look like it did in ST2!
You can see the effect of turning it off by comparing the right sides of the single pair of (before/after) screenshots in the article.
Also, after discovering this I Googled it and saw that some other people mentioning it (no hits for the other settings) in connection to the Soda theme, so maybe if you are using that it might already be disabled? I'm not sure.
Its distinguishing feature is that it's a regex library that matches streams (hence 's'regex).
> A boolean that if true enables a special debugging text renderer. It seems to turn sections of the document either blue or red, and within the sections it turns tokens alternating light and dark shades of those colours. Note you have to set the setting to false to turn it off, not just delete it. These change sometimes when scrolling and editing but I can’t figure out when and why.
That sounds exactly like GPU layers in web development - green is GPU accelerated, red is unaccelerated.
It has a GPU back end so it can be pretty fast, but it is still focused on very high quality antialiased rendering so it isn't crazy fast. Apps like Chrome and Sublime don't repaint the entire screen every frame or when scrolling, only the parts that change, so they can afford high quality.
That being said for a game you'd probably be better off with a higher level engine that also manages the scene graph, spatial sorting etc things for you unless you want to work on that part yourself.
Quite possibly leveldb, listed immediately above snappy, which can optionally compress content with snappy.
I would also be more skittish if I was looking at the license key validation code, but I didn't since I bought a license a long time ago (it was totally worth it).
Pretty standard contract law really, and the 9th circuit agreed, finding in favor of Autodesk in Vernor. But hire a lawyer if you need to know for sure.
And you generally cannot use software without first installing it to a hard drive so obviously it should be treated as a part of "usage", not "making a copy". Like playing a DVD is just usage, not making a copy. But of course the law doesn't always follow common sense.
I think that making copies for oneself (as long as one doesn't distribute them) should not be regulated by copyright too.
The Berne Convention says:
> Authors of literary and artistic works protected by this Convention shall have the exclusive right of authorizing the reproduction of these works, in any manner or form.
> It shall be a matter for legislation in the countries of the Union to permit the reproduction of such works in certain special cases, provided that such reproduction does not conflict with a normal exploitation of the work and does not unreasonably prejudice the legitimate interests of the author.
So it is possible to permit making copies for oneself under Berne Convention if the lawmakers wanted that. For example, law allows to record TV programs.
Sublime is faster and is crazy polished. It also has a larger plugin ecosystem.
Please backup claims with evidence.
There is no mystery in principle. Take Scintilla if you want to study editor in source code. That is straightforward implementation but works well enough.
As of syntax highlighting ...
You can use either regexp'es or, which is better, some predefined tokenizers.
Pretty much all programming languages have concepts of NMTOKENs (keywords variable names), string literals, numbers, comments. You can write very fast tokeneizers/scanners that will give you basic blocks. If needed you can pass these blocks to regexp for further processing. That will give you very fast processing.
If to deal with markup languages then use separate tokenizer. Almost 10 years ago I've written this: https://www.codeproject.com/Articles/14076/Fast-and-Compact-... , tens of megabytes of XML/HTML processing per second...
And yes I read lots of Scintilla's code years ago.
I did a couple hours of disassembly reading purely out of curiosity and to find exactly the kind of hidden goodies that I ended up finding.