4 ms·
I went from vim to emacs with evil mode (i used the doom distribution, which I think is great). However I went back after some months of usage. The main reason
by fileeditview 6y ago
I went from vim to emacs with evil mode (i used the doom distribution, which I think is great). However I went back after some months of usage. The main reason is performance. Many plugins are just not very performant with elisp but without them emacs is pointless for me. Also vim has better support for more languages in terms of LSP. In emacs I ran into a lot of outdated plugin issues.
I have customized my vim now with shortcuts very similar to Doom/spacemacs and many plugins. I am very happy with my setup at the moment. I don't care if it is against the vim philosophy as long as I get stuff done with it :)
My tip: if you want to try out emacs with evil, try the doom distribution. If you become a convert you still can configure your own if you want/need to later on.
- rthomas6 6y agoInteresting. I am a bit behind you and have recently transitioned to (Doom) Emacs. What plugins were slow for you? What things did you find indispensable and reimplement in vim?
- fileeditview 6y agoTo be clear, my issues were mostly not with doom but with emacs plugins themselves. Well Magit was clearly the slowest. Used in big repos with a big list of changes it grinded for minutes before showing the "status" screen e.g. Also various code completion plugins via LSPs were significantly slower than even VSCode and of course vim. While typing I often encountered lag even on fast systems. Not sure if the lag actually came from the LSP plugin or from something like Flycheck ui. TBH the one thing I "reimplemented" was the keyboard shortcut system which extensively relies on leader(s). In the beginning I just mirrored doom shortcuts but after a while I customized, more suitable to my own needs. Not really related to emacs but the vim plugins I would not like to miss are especially: coc.nvim, fzf.vim, ranger, vim-fugitive, vim-mergetool, vim-bookmarks
- phxonrails 6y agoI'm in the same situation. Started with Vim. Tried out Spacemacs and loved it. Switched to Doom for the performance gains. Finally, switched back to Vim (Neovim) with Doom-like keybinding; specifically setting leader to Space. I haven't found anything that comes close to vim's performance as a text editor. In terms of plugins, there are some great ones for Neovim like tpope's rails plugins, coc.nvim, fzf, etc.
- narwally 6y agoI just switched to Doom from a very trimmed down and customized version of Spacemacs. I liked Spacemacs layer concepts, but many of them I had installed for very basic functionality like syntax highlighting and code formatting, but to get that I had to pull in this huge layer containing multiple packages. Emacs was constantly getting bogged down by Spacemacs or becoming buggy at my attempts to speed it up. Doom is so much better on the performance end, I don't feel the need to keep an emacs server running all the time just for occasional editing in the terminal. I'm interested to see how well it performs with emacs-native-comp. The Doom ui also feels a lot more cohesive. I've never been a vim user, so I use the default emacs bindings but still have a leader key; Doom's setup with the leader key is really well thought out and I'm glad that vim concept has made its way to emacs.
- deleted 6y ago[deleted]
- deleted 6y ago[deleted]
- sirn 6y agoI would suggest a step further: start with Spacemacs/Doom, but if you decide to stick around, try to build your own Emacs configuration based on the part of Spacemacs/Doom that you like. Thanks to the amazing use-package[1] macro (which Spacemacs/Doom also uses) most configurations are self-contained to a certain extent. Searching for use-package in GitHub[2] will yields plenty of results which can be mostly be taken as a reference for your own liking. It should be relatively easy to port part of Spacemacs/Doom to vanilla use-package, e.g. starting with this (which sets up use-package alongside with evil): (require 'package) (setq package-enable-at-startup nil) (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/")) (package-initialize) (unless (package-installed-p 'use-package) (package-refresh-contents) (package-install 'use-package)) (eval-when-compile (require 'use-package)) (use-package evil :ensure t :config (evil-mode t) (use-package evil-leader :after evil :ensure t :config (evil-leader/set-leader "<SPC>") (global-evil-leader-mode t)) To add Magit, one could take a look at Spacemacs's git/packages.el[2], search documentation on what each package does, and proceed on porting configuration, only the part that you actually uses, e.g.: (use-package evil-magit :ensure t :after (magit evil)) (use-package magit :ensure t :config (evil-leader/set-key ("gs" #'magit-status)) Since most configurations based on use-package are self-contained, when stuck I also like to use GitHub search to look on how other people configure a certain package[3]. In most cases the configuration should be reusable as-is. Finally, use-package is highly extensible. There is straight.el[4] which adds extension to use-package to fetch from Git and pin a version in a lockfile, which adds reproducibility to Emacs configuration. There's also el-patch[5] from the same author that allows patching package on the fly without the need to maintain separate forks. [1]: https://github.com/jwiegley/use-package https://github.com/jwiegley/use-package [2]: https://github.com/syl20bnr/spacemacs/blob/d46eacd83842815b24afcb2e1fee5c80c38187c5/layers/%2Bsource-control/git/packages.el https://github.com/syl20bnr/spacemacs/blob/d46eacd83842815b2... [3]: https://github.com/search?l=Emacs+Lisp&p=4&q=use-package&type=Code https://github.com/search?l=Emacs+Lisp&p=4&q=use-package&typ... [4]: https://github.com/raxod502/straight.el https://github.com/raxod502/straight.el [5]: https://github.com/raxod502/el-patch https://github.com/raxod502/el-patch
- narwally 6y ago