Yes.
> cross platform support
Yes.
> Because you can write plugins in JS?
Yes.
---
As much as I prefer native programs as a user, it's impossible to ignore the benefits of cross-platform development and plebeian hackability/debuggability.
> Yes.
WOW FINALLY SOMETHING that will run on my LINUX and FreeBSD!
ohh.. a lot of plugins don't support linux and it doesn't build on BSD?
doesn't run on ZX Spectrum either
Note: I don't use VS Code or any other JS editor, I use emacs. But I can definitely appreciate the major benefits of the architecture.
both projects are open source if you care to verify
its a simple checkpoint and pretty much every actively developing project does this nowadays.
The whole experience is important. For many, it's more important than the individual 'feature' of being light on resources.
I currently ignore the fact that VS Code is 'heavy' as text editors go, because it's so much lighter than e.g. Visual Studio, leaving me much more RAM free for some of the code I'm running to gobble up and use for its own ends.
I'd prefer lighter 'weight' - in terms of RAM and CPU usage - but I'm not tempted back to Sublime yet.
BTW I'm a vi person, so I'm using vi keybindings in VS, VS Code, Sublime - and anywhere else I can do so. I love Vim's speed, but I can't Get Stuff Done in it like I can in more modern editors. I mastered the keys, not the inbuilt windowing system, scripting language, etc.
I really believe that if you find these vim plugins useful you don't really use vim all that deeply. that's not a criticism, just an observation.
Anecdotally I was able to create the cursor problem by minimizing/showing the VSCode window while viewing CPU usage DESC in task manager, but the effect was only ~2% usage for me (i7 processor).
If one invisible (from a UX perspective) bug is VSCode's big performance problem then I'll gladly let it eat away at 2% of my CPU until it's fixed.
I once wrote a visual PostScript debugger for NeWS, which I primarily used for debugging itself. [1]
[1] http://www.donhopkins.com/drupal/node/97
The PSIBER Space Deck is a programming tool that lets you graphically display, manipulate, and navigate the many PostScript data structures, programs, and processes living in the virtual memory space of NeWS.
The Network extensible Window System (NeWS) is a multitasking object oriented PostScript programming environment. NeWS programs and data structures make up the window system kernel, the user interface toolkit, and even entire applications.
The PSIBER Space Deck is one such application, written entirely in PostScript, the result of an experiment in using a graphical programming environment to construct an interactive visual user interface to itself.
One situation, I open 5k LOC file, scroll to the middle and bam colors are there everything was instant. In VSCode I open same file, slight delay, opens the tab, I click on middle of side codetree, slight delay, and few seconds for colors to draw. This is just one example. And there are those slight delays all over the place that I don't have with sublime, emacs or vim.
Especially with large files, but just in general. Speed is the main reason I can't stay using Atom for more than a few hours. It's awful.
VS Code is snappier than Sublime Text ffs...
Now if I was coming from a larger, probably Java, IDE? Yeah, I can see that Atom would look great.
Just wasn't for me. Glad you like it tho!
Sublime had the edge in a couple of cases, but when opening large files (esp JS bundles) it crawled. Took over a minute to open one.
Same file in VSCode - maybe a couple of seconds. Maybe.
Is for me. Not by a lot, and not in every case, but overall? Is for me.
There are a huge number of plugins for VS code. It's built to be plugin-centric - most functionality is a plugin.
...indexing...
...as I was saying...
Performance & bugs/quirks. I'd much rather have performance.
I mean, Emacs had jokes about being bloated decades before Javascript (and Java, another contender for these jokes) even existed. :)
I don't think running Elisp in Emacs takes away from it being "native." At least insofar as there are no popular text editors (that I know of!) which expect you to compile your plugins and macros to native code. They all have interpreters of one kind or another. What Emacs doesn't have, though, is an inner platform effect: Emacs is the platform, there isn't a second one underneath (no browser engine).
If you use a Common Lisp based editor like Clozure CL, Allegro CL and LispWorks have, they don't use a C-based byte code interpreted. The Lisp code is compiled directly to native code. Which makes editor extensions running in natively compiled Lisp code.
The advantage of the c-based byte code engine is compact code and improved portability - since the C compiler will already be provided with most platforms, whereas a native Lisp compiler is typically not something provided by a platform (CPU/OS/...) vendor...
If forced, I would say that Emacs-the-platform is native, and Emacs the system of Editor MACroS is not, since the macros run on the Emacs platform. But it seems kind of pedantic.
The number of lines of Elisp my Emacs uses (counting plugins, but also built-ins) is actually more than twice the number of lines of C.
It's not that "Emacs contains an interpreter", rather it's "Emacs has all these features written in Elisp [...a looong list here...] Oh, and it also has an interpreter to execute it all".
Some features like memory management (garbage collection) are layered on top of the OS.
The UI is not 'native' - it's based on a portable substrate written in C/Lisp, which works both on WIMP and terminal systems.
The user interaction is not native (commands, buffers, undo, preference dialogs, window/frames, ...).
etc.etc.
Let's just agree to disagree. We are talking past each other at this point. Best regards!
Because compiling code to the native instruction set shouldn't affect the semantics: so why should that be the only yard-stick for "native", right?
What is semantically relevant is: how much of the platform is exposed to the programs directly, versus through abstractions.
Suppose a language like Emacs Lisp or Java or whatever has only thin wrappers around POSIX through which applications interact with the platform. Then those programs are quasi-native POSIX programs, really. They are doing things like fork, waitpid, dup2 and whatever almost directly. And suppose that in the Windows version of that language, programs use functions that mimic CreateProcess or WaitForSingleObject. Then, regardless of the language being interpreted, it's really a native programming language.
As such I simply found emacs an odd choice as an example.
BTW: Notepad++ uses .dlls as plugins. (Which doesn't neccessarily make it a better editor than emacs :) )
Having said all that, I don't think that "non-native" is a pejorative. I use Emacs, but would switch to a "non-native" editor if there were a good reason. I use IDEA (native or not? you decide!) when working on big Java projects, and Emacs for everything else, because Emacs affords me a lot of power that I find lacking in other editors. "Nativity" isn't really part of the equation, it's really about functionality.
As such GNU Emacs is just as 'non-native' as a JVM-based editor.
Example: the calculator of GNU Emacs. https://www.gnu.org/software/emacs/manual/html_mono/calc.htm...
:)