Hacker News Reader

Comment by zitterbewegung | Hacker News Reader

VS Code is an acceptable emacs

Not until it gets something akin to helm/ivy/consult.

I like emacs and have been using it for like 8 years, and doom makes my additional configuration small and manageable, but I’d switch to vscode in a heartbeat if it was possible to replicate basic features of an extended emacs. I just want a good editor at the end of the day.

* wgrep is hugely useful.

* Fuzzy searching with orderless is unmatched in any other editor. Being able to resume is hugely useful. Being able to plop the results into a saved buffer is hugely useful.

* magit is the only way to do complicated rebases.

I really want to move on but until vscode fixes their search, I’m stuck. I can live without a good git interface, I can’t live without navigating projects in a grep-oriented way.

Vim doesn’t have this either, by the way.

> magit is the only way to do complicated rebases

I use this

https://marketplace.visualstudio.com/items?itemName=kahole.m...

It's a start (and I use it too), but it's so far from parity with Magit that even when working in VSCode (where rust-analyzer is better), I often switch to Emacs for Magit.

I feel it

when edamagit fails me I rely on smagit

I've never been proficient enough with Emacs, no matter how much I tried,but Magit is its killer app

https://github.com/maio/smagit

>Vim doesn’t have this either, by the way.

look into fzf vim plugins.

I’m aware of denite/fzf/telescope/clap. They don’t come close to what’s possible in emacs.

While I'll agree that you can't accomplish all that's possible in Emacs in vim, I'd love to know what you can accomplish using fuzzy search in Emacs that you can't in vim.

https://karthinks.com/software/fifteen-ways-to-use-embark/

I agree about all of these things. But there's one thing vscode has and emacs doesn't that has recently (as of a job change) caused me to switch, because it ended up trumping everything else:

  * works decently well on Windows

Emacs is just so so so painfully slow on Windows. And running the Linux version in WSL leaves me stuck in 16-color terminal mode because (at least as of Windows 10) getting an X server working on Windows without creating a security problem for yourself is, to put it mildly, easier said than done.

Interesting. Another reason for me to not touch Windows, I guess.

Sorry about being stuck on Windows 10, but Windows 11 has WSLg[0], which gives you a reasonable X server out of the box. I liked X410, but WSLg is seamless. When combined with no fuss CUDA support and great docker integration, WSL2 on Windows 11 is almost a better Linux than Linux. Then you run into an edge case, spend hours digging at it, and leave curled up into a fetal position.

[0]: https://github.com/microsoft/wslg

Exempt its installation folder (and any folders where you keep a large number of Elisp files) from Windows Defender and other antivirus software. Does that help?

The issue is fairly well documented. In a nutshell, it's that the Windows kernel has rather high-latency disk I/O, and emacs plugins tend to spam the disk.

I use mobaxterm on windows which has an X terminal builtin (IIRC). I've never actually had to use it - I just the the ssh/rdp/scp stuff. But its free to try it...

I've used Emacs on Windows for over a decade. Other than magit I've not noticed it being any slower than it is on my Linux machine.

I don't use WSL

I use all of these in emacs, but IntelliJ has equivalent functionality without any plugins. Complicated rebases are much more easily done in IntelliJ than Emacs because I can edit and pick-and-choose changes while inside the 3-way diff view, while in magit, as far as I know, I must do it separately from the diff which makes things harder.

Was only half serious. Other than if you are in a situation where you can't install emacs and or its packages its amazing.

The most annoying thing to me about VS Code is it cannot be extended in a way that doesn't require developing a plugin. In short there is no ~/.vscode.ts. Instead you have to create a plugin to add custom commands.

I say this a a former emacs user now using VS Code.

You can write an extension which evals a JS file to recreate this

You sure? I don't think VS Code is open-source (happy to be proven wrong) and that's an important part of Emacs.

https://github.com/Microsoft/vscode

https://github.com/VSCodium/vscodium

It's not the important part of Emacs for everybody though.

Perhaps you mean Free Software rather than Open Source? Parts of VS Code are open source but they are not Free Software.

Arguably not without a Lisp-based implementation and extension language.

That said, as a multi-decade Emacs (and Lisp) user, I do like VS Code and its JavaScript/TypeScript basis.

On the surface that appears to make no sense at all. Do you mind being a little more descriptive?

Among developers, probably the most popular text editors are VSCode, vim, and emacs.

On a spectrum of "notepad to IDE", vim is closest to "editor only"; although with effort it's possible to get an environment with nice bells & whistles.

Emacs has always been 'heavier' than vim (although I don't think it's "works well out of the box enough" to count as an 'IDE'). A couple of ways in which it's heavier is e.g. its fancy UI for customising properties; or its "apps" like org-mode or magit, or having an elisp shell or support for virtual terminals.

VSCode's also not quite an 'IDE'. But it's also heavier than just a pure 'editor'.

VSCode doesn't quite have the insane level of customisability that Emacs has. VSCode also doesn't have people bragging about e.g. reading email from VSCode. -- But, VSCode does have some of these features (e.g. an 'app' for interacting with Git, or inbuilt terminal).

I like to think that VSCode's discoverability owes a bit to Emacs (e.g. the key bindings showing in the command palette reminds me of emacs' which-key).

Thank you. I thought you were getting at some kind of fundamental alignment between the two products, but as I see it, you view VS Code as a product it’s as extensible as Emacs, or something close

Reply on news.ycombinator.com