> Intellisense

Could we please call it "autocompletion" instead? The feature did not originate from Microsoft IDEs, and while they are free to call it whatever when talking about their editors, the rest of the world (well, that 2m^2 part centered on me, at least) would appreciate if we used more general terminology.

I think the generic term for this feature is "code intelligence". Autocompletion often just means that the editor provides suggestions of other symbols in the same file, which is a far call from the language-aware and context-aware suggestions, auto imports and refactoring features IDEs provide.

The distinction seems important as I personally wouldn't go back from VSCode to an editor that merely provides autocompletion but can't reason about the language beyond basic syntax highlighting.

I caught myself using "Google" as a verb when talking about searching on Amazon the other day and "Xerox" has become synonymous with "copying" for an entire generation, so I wouldn't judge too harshly on people using "Intellisense" as a generic phrase even if it can harm communication ("But does this editor have Intellisense?").

GTAGS/CTAGS/"any other family of tag processors/generators" could be used for autocompletion in Emacs/Vim way before, and they were just "part" of autocompletion.

I'm ok with "code intelligence", or even more precisely "autocomplete based on code intelligence". All good. Just not "intellisense", please ;)

> I personally wouldn't go back from VSCode to an editor that merely provides autocompletion

Autocompletion can draw from multiple sources. By default, before LSP hooks have a chance to add themselseves to the list, I have following sources configured:

      '(ac-source-symbols
        ac-source-variables
        ac-source-functions
        ac-source-features
        ac-source-filename
        ac-source-abbrev
        ac-source-dictionary
        ac-source-words-in-same-mode-buffers
        ac-source-semantic
        ac-source-yasnippet
        ac-source-files-in-current-dir) 

Maybe that's why I don't think changing the name of the feature based on just the source it uses makes sense.

I always understood "intellisense" as a way to say "contextual autocompletion based on structured information". So it is a form of autocompletion, but one that adapts gracefully to the context (like an IDE autocompletion experience). Autocompletion could just mean that you have some string matching (more like basic shell completion).

It's good to have a way to specify when you're talking about the former meaning and I do not know another term for this than "intellisense".

+1 to this. A lot of basic text editors have basic string-based autocompletion. Intellisense is way more than that. IntelliJ (atleast PyCharm) excels at this too.

In my experience, "Intellisense" is shorthand for "broken autocompletion"

I don't use Microsoft IDEs often, but have had experience with them many times over the past 15 years. And every single time, intellisense would freeze, get confused, or just stop working completely. Not once in 15 years have I had a passable experience with it, so nowadays when I'm in Microsoft land I always immediately disable intellisense before I start working.

I completely understand your feelings. I also always faced quite a lot of issues with Visual Studio (not vscode) autocompletion when trying to write C++. But when it decides to work the experience is great.

Visual Studio Code on the other hand is just fantastic. I was a hardcore emacs user until I switched to VSCode as my main editor a few years ago due to the crazy good auto-completion experience.

I could’ve written this comment. I made myself use VSCode for about a week, and that was about the last time I seriously used Emacs.

I had the privilege of chatting with the VSCode booth people at PyCon a couple years ago. I was waxing enthusiastic about some feature or another and one of the other people at the booth spun around — “I wrote that!”, and then I got to tell him how much I loved his work. That felt great.

Intellisense is a collection of dozens of IDE features and is far more than just autocomplete

I think at this point it's safe to assume Intellisense is fairly genericized and refers more to an "autocompletion" that takes additional information/context into account than a specific $company's implementation.

This is a little teaser of some of the more easily demonstrated visual changes in ST4, but we've got a huge collection of new features, tweaks and bug fixes coming.

The community is actively maintaining an LSP package, and we've added a number of features in ST4 that the protocol requires, such as UTF-16 diffs.

I love sublime text, but I really wish you'd reconsider relying on a community LSP package. There was an issue a year or two ago where the LSP package couldn't be installed due to a dependency issue in the package, and since it's a community package, they could only fix it when they had enough spare time. I think it was a 1-2 month timeframe where there was no way for new installs to have LSP functionality since it required a third-party plugin.

We looked into the protocol, but unfortunately it made a number of poor architectural choices that leads to many language servers not implementing the protocol properly. This effectively requires custom integrations for most language servers. That wouldn't make sense to do in the core of the editor, since we'll never be primary users on the vast majority of servers.

The open source model makes sense since it will need to have tweaks and fixes to support various language servers. That combined with a very small development team (six engineers across our two products), would probably lead to slower development, and it would be tied to the release cadence of the main product.

That's unfortunate, but I still think it would be best if you could at least add support for one or two servers in the core, with extensibility for others. Or officially adopt and support the community LSP plugin. My experience with the community LSP plugin has not been good, and it almost led met to switch to vscode. (That and debugging which is a whole other can of worms.) I really think working on LSP would be a better use of your time than continuing to improve the current fuzzy indexing engine.

The problems you're likely had with the community LSP plugin were due to a lack of APIs provided by ST. For ST4 we've worked together with the community LSP plugin authors to properly support it.

That makes sense, I didn't know how small the team was. Thanks for the response, looking forward to ST4.

I'm really excited about the new release, thanks for building one of the fastest text editors in the game. I use it every day and couldn't develop without it.

I use sublime.txt everyday. The main purpose is reading, editing, searching a “scratch.txt” file I have been prepending to for the last 11 years. Sublime loads, saves, and searches it better than any other text editor. I have found it’s a helpful way to save random lists, notes, links, and common chunks of code.

It’s also my go to for wrangling weird txt.

I have a similar use case, although I am not a power user.

I use it to open often giant .csv and .txt very very fast. I use it to quickly edit SQL because the select-lines command (ctrl+alt+up/down) makes batch edits of indented code a breeze. I use it to sometimes format and arrange weirdly formatted C#. I use it often for its lightning fast search and replace function.

It has grown on me over NP++ which is still a very very nice text editor.

I still use sublime text everyday. By far the boot speed, zero lag between file changes and other slight annoyances are not there. Plus the integration of Sublime Merge has been fantastic.

Me too -- I live in Sublime Text most days. Hard to argue that VSCode wins on dev features, and most of my fellow developers use it for that reason. But I can't get past the speed; Sublime Text does everything instantly, while in VS Code, everything is just slightly laggy.

To each their own, I guess, but given how much of my day editing text, it's hard to want to use a text editor that has noticeable lag. (Cue the usual rants about latency in 2021 on multi-GHz machines)

I've also got most of the shortcuts committed to muscle memory and configured just the way I like it. Sunken cost fallacy is where I am headed. But I've always loved this editor and will continue to support it as long as they continue to support it.

I also love sublime merge, any time im screensharing with someone pairing on some code and we finish up i pop it open straight from sublime to review our changes and they always want to know what tool it is. They just produce really great software.

Sublime still holds king for ad-hoc grepping around large files.

For dev work though, my daily driver is VSC at this point.

I still use Sublime for notes as well, but that's more so I don't have to think about how closing/opening half a dozen workspaces in VSC affects which notes are open.

I basically use Sublime in place of notepad on Windows at this point. If I need anything beyond advanced text editing; I'm using an IDE.

I use Sublime Text as excellent grep/search tool. Superfast, easy to write filters for include or exclude, can quickly open the matching file and you can see it with proper syntax highlighting.

then why not use notepad++ its free and open source, unlike sublime text

Wasn't one problem that Sublime Text's plugin API was somewhat lacking, you couldn't do any advanced GUI in it?

This is a big one. Being able to create a tab/window to view custom data would be awesome, like a live HTML preview, OpenGL surface, graph rendered from an open data file, custom image format, etc.

I wouldn't mind the core ST app being so bare bones if the plugin API was more powerful, but unfortunately it is pretty limited in what you can do.

We've got quite a number of API enhancements in the next version, including HTML sheets for non-text content.

That said, we are definitely focused on being first and foremost a really fast text editor that makes it easy to read, navigate and write code. Trying to implement a browser or be an IDE are outside of our area of focus.

Jetbrains is extremely fast for me these days because the indexing is good. The fact that the IDE and Java are using 1-2 GBs RAM isn't really a problem when any dev machine is going to have at least 8 GBs.

That's surprising. I used IntelliJ today after a pause and found it unbearably slow. For instance, scrolling a ~6 page source file lags so much it's extremely irritating.

It's also fantastically bloated. There's so much stuff I have to disable to make it barely usable. And most of the supposedly helpful lightbulbs suggest changes that make absolutely no sense.

I can absolutely believe that IntelliJ has its fans because it has a ton of features, but for me it's just unusable.