When a power supply gets old, wonky things start happening and the computer becomes unstable in weird ways. I am not sure the computer/power metaphors are the best fit.
This may or may not be true - just because we haven't seen GPT-level-5 capabilities, does not mean that it does not yet exist. It is highly unlikely that what they ship is actually the full capability of what they have access to.
"Which would be at odds with sending data up to the cloud for processing"
I don't think there is enough information here for that to be a true claim - it is possible to send the input used for inference, to the cloud, while computing the result locally. It is also possible to store the input used for inference while offline, and send that later when the device is online.
Speaking from personal experience, I moved from VSCode to Doom Emacs a year ago, and the on-ramp wasn't nearly long or as tough as I thought. The defaults are good, and anything else that I customized I actually just used ChatGPT/GPT-4 to generate it. It took about a month to get used to the new setup. With LSP/Magit, it feels like I'm not missing out on much from what VSCode offered, and then whenever I want to personalize it, I can. For a creative person (which I'd argue most developers are, kind of by definition), it's fun.
I've been using Emacs for roughly three decades; it's my favourite editor. And for sure, LSP has been an absolute game changer.
Worth noting is that LSP came from Microsoft as part of their efforts to build a better editor experience; and its integration with VSCode is largely unparalleled.
For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality. If you're savvy enough you can install lsp-mode and it will add that functionality, but at that point you may as well just install the language server yourself.
And about magit: it's a beautiful piece of software, it truly is. It's also hot garbage with large repositories hosted on Windows. I simply cannot use it for work because every operation takes around a minute to resolve, which locks up Emacs entirely. Again, here VSCode shines because the default git integration is pretty good, and there are extensions that make it excellent.
For these reasons, and more, I always recommend VSCode to new developers and don't recommend Emacs. Emacs is for people who want to make editor customization a _hobby_.
>For example: in VSCode the user doesn't have to understand how to install a language server, it just automagically suggests allowing it to install one for you. In Emacs, if you're using the official distribution you will have eglot, whose developers specifically refuse to add that functionality.
I can understand this not being friendly for some users, but on most systems that people are using Emacs on, software is installed through a system package manager and not downloaded and unpacked into ${HOME}. I do not want software that isn't the system package manager to install LSP servers.
Maybe this is more of an issue for people using Emacs on Windows, since there is no system package manager, and people are less likely to understand how to install stuff.
"savvy enough" for emacs these days for lsp is literally "M-x package-install lsp-mode"
Earlier today I started up emacs in a C++ project after working exclusively in Rust, and I didn't have an lsp server for C++ installed. I did M-x lsp-mode and it prompted me (paraphrased): No language server for C++ installed, do you want me to go get one for you? Options are: clangd. Sure, said I, and it just went and installed it and off I went.
Granted, you'll also need company-mode and stuff, yes. And to get an IDE like experience... treemacs, projectile, etc. etc.
Yes, it's an acquired taste. But it's not like it's obsolete. It's better and more active than it's ever been. And I've been using Emacs (mostly casually) since 1992.
I was gonna mention that installing lsp-mode is as easy as clicking 'Options->Manage Emacs Packages', scrolling down to lsp-mode, clicking it, and clicking 'Install', however it turns out lsp-mode isn't in GNU or NonGNU Elpa, so it requires setting up MELPA first. So unfortunately it isn't entirely tech journalist friendly.
I'm sorry maybe this has improved in the two years since I tried but the last time I tried to set up VSCode to even approach the capabilities of CLion (the tool I used most at the time) it required a whole bunch of configuration, and stuff that felt more brittle and confusing than the emacs setup I have now.
In particular, no, it did not do all the LSP stuff out of the box, and didn't do basic refactorings out of the box either. Maybe it does so for other languages? Or maybe they've fixed the UX? But I recall having to install at least two or three plugins. And along the way found some that fought with each other.
I have never used VSCode for C/C++, only Emacs and Visual Studio, so I can't comment on how it compares to CLion. VSCode and C#, however, is something I prefer to Visual Studio or even Rider.
> Emacs is for people who want to make editor customization a _hobby_.
I disagree. I use it for org mode to take notes, track time, and write documentation. I use it with SLIME to program in Common Lisp (side projects, though). I make changes to .emacs or write an elisp function once in a while, usually to finesse something that I do frequently, but it's definitely not a hobby. It's a great tool, even before any customizations, IMO.
I've also been using Emacs for 3 decades. Although I could probably be happy with vscode for coding, neither vscode nor any other app I am aware of is a satisfactory substitute for Emacs as a personal information manager (PIM) because neither vscode nor any other app can be modified easily enough. (Apparently, I care whether my PIM supports my personal way of working more than I care whether my code editor or IDE does.)
Maybe if I were a professional web developer, I would be able to modify vscode in the ways I feel it needs to be modified to support my personal style after a reasonable investment in learning vscode internals, but that is manifestly not actually the case.
