3 ms·

- Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows - That I don't need to switch out of emac

- Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows - That I don't need to switch out of emacs for git (magit is great), complex file operations (dired), and other things like repl/shell/complex rgreps/etc - Vim keybindings. I know this isn't related to emacs, but with Doom emacs I forced myself for the first time to rely much more on keybindings. I could probably do something similar with vscode, but it's not built for this and doesn't encourage it. It's painful in the beginning, but over time you're much faster with these keybindings. - In general, I feel like I can customize it. I feel like I have control. For example, I had a painful time managing nested projects using multiple languages in vscode. The LSP extension's "defaults that work most of the time" get in the way when you're doing something that's a bit esoteric. With emacs I can easily customize it. This is just one example, but the point applies in general.

zelphirkalt 4y ago
> - Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows This. So much. The number of times I have seen people fumbling around with multiple VS Code windows and closing and opening it again in another directory, because the working directory wasn't right and switchting between loads of tabs they opened, overflowing the tab bar ... It isn't even funny any longer. Another point to that is, that in Emacs I can press `C-x 1` at any time to get everything except the current buffer out of the way, using all the screen estate I want for some buffer, be it a shell or a code buffer. > - That I don't need to switch out of emacs for git (magit is great), complex file operations (dired), and other things like repl/shell/complex rgreps/etc Same here. I feel like I get things done in git 3x faster than what I see people do in VS Code or IntelliJ based IDEs. I just know my keys and do it much faster, which leaves me more time for the actually important thing: The commit message. Also being able to copy commit ids and branch names out of the magit version of log (M-x magit-log RET -c b if my favorite) avoids typos and improves my speed. Add to that the fact, that of course Emacs stores last used commands of M-x. Or interactive command input history, which one can cycle through easily. On occasions, when a refactoring is needed, most of the times I can do it quickly via opening dired, moving the point to the directory I want to replace in and pressing Q. This basically always works, but does not have knowledge about the programming language. On even rarer occasions, I can feel a bit of regret of not configuring my Emacs even more, to support refactoring for Python. But I am sure, if I had to do it more often, I would put my mind to configuring Emacs and would configure it to have better Python support. Probably I can just find a tutorial in 1min of searching for it. So people can tell me stories about how their IDE is more efficient all day, until they can show me they are up to speed for all the other actions besides refactoring with language understanding, which only happens rarely, I will not be convinced, that it would make me faster.
- ossusermivami 4y ago
  I have been using emacs and dired for like a very long time, and never knew about Q operations from dired. I used to do rg + edit mode... I guess this is the thing with emacs, you always have something to learn...

zelphirkalt 4y ago

> - Emacs buffer, window and project management. I wasted so much time in vscode navigating across projects and windows This. So much. The number of times I have seen people fumbling around with multiple VS Code windows and closing and opening it again in another directory, because the working directory wasn't right and switchting between loads of tabs they opened, overflowing the tab bar ... It isn't even funny any longer. Another point to that is, that in Emacs I can press `C-x 1` at any time to get everything except the current buffer out of the way, using all the screen estate I want for some buffer, be it a shell or a code buffer. > - That I don't need to switch out of emacs for git (magit is great), complex file operations (dired), and other things like repl/shell/complex rgreps/etc Same here. I feel like I get things done in git 3x faster than what I see people do in VS Code or IntelliJ based IDEs. I just know my keys and do it much faster, which leaves me more time for the actually important thing: The commit message. Also being able to copy commit ids and branch names out of the magit version of log (M-x magit-log RET -c b if my favorite) avoids typos and improves my speed. Add to that the fact, that of course Emacs stores last used commands of M-x. Or interactive command input history, which one can cycle through easily. On occasions, when a refactoring is needed, most of the times I can do it quickly via opening dired, moving the point to the directory I want to replace in and pressing Q. This basically always works, but does not have knowledge about the programming language. On even rarer occasions, I can feel a bit of regret of not configuring my Emacs even more, to support refactoring for Python. But I am sure, if I had to do it more often, I would put my mind to configuring Emacs and would configure it to have better Python support. Probably I can just find a tutorial in 1min of searching for it. So people can tell me stories about how their IDE is more efficient all day, until they can show me they are up to speed for all the other actions besides refactoring with language understanding, which only happens rarely, I will not be convinced, that it would make me faster.

ossusermivami 4y ago
I have been using emacs and dired for like a very long time, and never knew about Q operations from dired. I used to do rg + edit mode... I guess this is the thing with emacs, you always have something to learn...