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.
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 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.
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.
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...
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 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.
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.
Comments
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.
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
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:
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.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
Interesting. Another reason for me to not touch Windows, I guess.
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 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...
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 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.
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/
Was only half serious. Other than if you are in a situation where you can't install emacs and or its packages its amazing.