People who switched from vim/neovim to emacs, what made you switch?

I been using Neovim for a while and am pretty efficient with it, and use vimwiki for notes. With that said, Is there any reason to check out emacs if I already know Neovim? My concerns for learning it are: 1. I heard Org mode is pretty good but how does it compare to vimwiki? 2. You can do a lot of computing stuff in emacs like checking emails and stuff, but is it practical / more efficient in emacs than doing it via GUI? 3. How does Emacs Lisp compare to vimscript / lua? 4. Are there any other features emacs has that neovim does not?

If you are a vim power user you probably won't gain much by switching. I side with the pragmatic programmers that it's better to master an editor, any one that is powerful enough, than to spend time comparing and contrasting to try to micro-optimize on the most 'powerful' one. From what I've seen of vimscript it looked terrible. Emacs Lisp v. Lua probably depends on how strongly you feel about lisps in general. I do think magit is the best git ui I've ever seen anywhere, I don't know that vim has an equivalent.

I have 20+ years of vi key bindings in my muscle memory. I tried vimwiki but it seemed to get in the way more than it helped me. Sorry but I don’t remember specifics. I moved to doom emacs so I could keep the key bindings that I know and for org. For me, it’s the best of all worlds.

I switched because I couldn't get the cursor in the neovim terminal to stop being a block. I wanted a vertical bar and that just isn't possible apparently. 1. Org is ... Different than vimwiki. The markup and editor integration is better, but the workflow is worse. There are a few systems for alleviating this such as `org-roam` and `denote`, but it's just not the same. Of course it's doable to hack something up for specific functionalities, which is what I've done (I can share the code but it's not in a good place yet). 2. It depends. If all you do is click around the gui, stick to that. The power of Emacs is in its text interaction and repeatable/composable functions. EG bulk renaming files or programmatically categorizing emails. 3. It's worlds better than vimscript, and (imo) cleaner than lua. Vimscript has this problem where things in the vim API are simple one-liners but anything else is a gigantic messy hack, and the language quirks are very alien and idiosyncratic because the "standard" syntax is already used for something different. Lua attempts to solve this with a straightforward syntax and more optimized execution, which is a step in the right direction. Elisp completely negates the problem by starting from the most basic editor constructs, and being a programming language first (and editor config format second). Emacs becomes the platform on which your code runs, and its UI toolkit, rather than just a language. Writing standalone scripts in elisp instead of shell is something I find myself doing more and more. Here's an example: in vim, keys are fundamental. To rebind a key is `map newkey oldkey` - internally it's plugging oldkey into the editor and it's got a layer between that translates. But in elisp, keys are bound to functions, always. In insert mode all the keys are bound to `self-insert-command` which puts the key that called it into the buffer. 4.a fundamental abilities: - proportional font rendering - different text size in split windows (allows for things like https://github.com/dengste/minimap) - Image display - smooth scrolling 4.b cool built in features written in lisp: - an interactive shell (`eshell`) that bridges the gap between bash and lisp - transparent (ish) remote file access (`TRAMP`) that also stacks with eshell - you can cd into remote directories like it's no big deal and Emacs will optimize the connection - TETRIS - org-mode which can execute code blocks and put them into files and is even programmable on its own, plus exports to almost every document format under the sun 4.c plugins I use - evil (basic vim navigation) + evil-collection (vim keys everywhere else) + evil-surround, evil-commentary (which are re-implementations of vim-surround and vim-commentary respectively) - general.el (provides straightforward key-rebinding functions including the vim ones) - airline-themes + powerline (yes, somebody ported all of the vim-airline themes to emacs) - eat (https://codeberg.org/akib/emacs-eat) (terminal that runs inside emacs and can use eshell as a shell) + eshell-syntax-highlighting + eshell-prompt-extras - helpful (what vim help pages wish they were) In conclusion, emacs is pretty cool and does almost everything that neovim can. You should check it out. Warning: the defaults are not good at all. Follow along with the YouTube channel "System Crafters" to get started.

I'd say that as a whole neovim is an attempt of vim community to catch up to Emacs in some ways. That's why neovim added lua plugins/scripting (compared with vim). I have personally used vim for 10+ years and was pretty proficient with it but I still struggled dealing with larger projects. My first use case for using emacs was actually email (notmuch). After that I kept adding things and now Emacs does my task tracking, file management, email, all my text editing, coding, notes (org-roam) etc. Tramp is another powerful feature which is a great way to edit remote files (not sure if neovim has something similar as a plugin?) I might still agree with @sisyphus that you probably won't be much better off with Emacs if you are a (neo)vim power user. Unless you are willing to expand your usage beyond basic text editing. To your actual questions: 1. Org mode (just like rest of Emacs) is infinitely malleable to what you need. Together with various export functions it provides ways to rite actual LaTeX papers, CVs, PDF documents, task tracking and more. I can't imagine vimwiki comes close. 2. It is for me. But then again - I admit even in my corner of the world I am a weirdo :-) 3. Well emacs Lisp is basically how the editor itself works. You can plug into almost every little bit of functionality. I assume neovim lua plugins are still more limited but at the same time those corner cases might not be that important most of the time 4. I would assume plenty depending how you count, but it goes both ways. I bet neovim has things Emacs does not. It depends what you care about. But even orgmode itself is a big enough draw these days...

> I moved to doom emacs so I could keep the key bindings that I know and for org. For me, it’s the best of all worlds. Same here, org mode and specifically org-roam motivated the switch. Doom Emacs to keep the familiar vi keys and to avoid having to write and maintain a config. I do use Neovim for editing scripts and most code though. At the moment I've got an Emacs for prose, Neovim for code split going on.

I switched because I thought I should give it a chance, fully expecting that I would switch back. There was stuff neovim didnt have that I wanted like good GUI support, multiple windows in same editing session, daemon support, etc. In the period I was trying emacs out, I was able to configure emacs to the point that I could not distinguish the two in regular use, and when comparing, I always had to double check which I was on. Except, in emacs, I could start integrating the features neovim didnt have into my workflow, thus it immediately provided more value. Over time, my config moved away from mimicking neovim to be more emacs native, but I have never missed anything from neovim, so no reason for me to switch back.

I was a hardcore unixer, so vimmer, for more than a decade. I switch to Emacs 5 or so years ago and not looking back. The famous single drop that overflows the vase was Ubuntu abandoning Unity desktop for Gnome SHell (second capital not a typo), for a long period of time after another long period of time with classic WMs interleaved with CDE (OpenSolaris SXDE before, SXCE thereafter) I was pissed off on one side because coming back to classic WMs means extra work I was not happy anymore to do, I have far less free time than back at uni so... I've decided the modern desktop reach it's peak of absurd involution and trying the old-new tiling WMs with i3. Nice, but damn limited. Then I see Emacs in action, and I start hearing about EXWM. I start with org-mode and notmuch, than EXWM. Then I almost fully jumped the ship keeping just a modern terminal emulator with my beloved zsh. I've tried eshell, still not get it much, I can use it, but I'm too slow, I still have various scripts laying around, most now tangled from org-mode as my desktop and whole home infra configs (NixOS, most of them) and that's is. YES, I do not switch much from Vim, an editor, to Emacs, what I call an Operating Environment or a modern classic desktop. I've just abandoned Vim because I almost abandoned the classic Unix CLI having switched to an X11/Emacs hybrid, witch is on top of Unix (well, GNU/Linux) just because I haven't a LispM and there a anyway no new ones on sale... Vim for me was the needed companion of a Unix shell, meaningless alone. The switch was from zsh+vim to Emacs. The residual part is only for the shell, not for Vim. NVim for me is just like fish vs zsh, witch means better defaults (even if it's far beyond that), and might be now attractive for me IF I'm on some system where I do not have my Emacs, simply because I do not have anymore a portable Vim config and update the old one is too time-consuming... Org-mode is much more, but the bare basic is an outliner, a kind of way to edit and present text that have popped up sometimes in history, for instance in the old Canon CAT, but that's almost forgotten and appear sometimes only in some IDEs to collapse/expand some source code, limited to specific programming languages. Compared to Vim wiki... Well, it's a textual 2D UIs that can glue anything locally. You can integrate in org-mode mails, feeds, reddit/HN posts, news, accounting stuff, code, ... anything live and anything in an intuitive and natural markup. I actually have my mails still in notmuch, sometimes wrapped via org-mode (notmuch: link types for individual messages, notmuch-search: link type for clickable queries, like to see all email from someone in an org-mode, org-roam managed note of some one) and yes, it's like having a local GMail WebUI, fully integrated in my desktop instead of a remote one I do not control and so I can't really integrate. Lisp, elisp more specifically, is simply an user-programming AND system programming language. Something as easy as write a script, but perfectly usable to write an OS kernel. So something that allow you doing the same you do with shell aliases/functions but in a far more integrated level. For other features... Well... In editing terms perhaps they do the same, but if you consider the lisp environment with stuff already integrated by someone else for mail, news (elfeed, newsticker, org-feed etc), accounting (ledger, ob-ledger etc), reddit/HN (nnreddit, nnhackernews Gnus backend and Gnus org-mode support), comfy package management, pdf support with various extras, ... in useful terms it do what Unix do on a CLI+Vim but all in a 2D UI who is also graphical, even if limited in what it support. 

I'm still in the middle of switching, though I'm mostly in emacs now. I switched simply because I needed two buffers of different scales and having different binds for switching between buffers/planes and windows got really annoying. I can only answer 3) as of yet, but lisp is far, far, superior to vimscript and (merely) a lot better than lua.

Emacs has better compatibility on Windows than Vim or Neovim. Granted, I don't use Windows much these days but the other comments here cover the other bases.

How did you get comfy in magit? I tried it out in a spacemacs setup and it was just annoying. I usually just have another tab open in my terminal for running git commands. I probably only use the following commands so my surface area of git usage is pretty simple /low Status Branch Pull -r Push (—force) Switch (-c) Rebase -i Add . Commit Remote origin prune

Elisp - it's obvious. vimscript is terrible, neovim was not introduced yet, but elisp is simple enough and very powerful

> The famous single drop that overflows the vase was Ubuntu abandoning Unity desktop for Gnome SHell Ha! Same here in terms of window managers (though I switched from vi to Emacs in 1994). After some failed efforts to make Gnome 3 comfortable I experimented with i3 that ended up as a stepping stone to EXWM. Though since then for various reasons I have reverted (via trying dwm, Herbstluftwm...). I prefer the compromises of a separate WM over EXWM, though there was a lot I liked about using EXWM.

1. Org mode is better, to mention one thing that org handles way better: tables. If you’re using the gui version of emacs, you can have images in your notes, that’s something I missed using vi wiki. Then there’s all the extra packages you can add, like org roam to make connections between notes, or org transclusion to inject the content from from one note into another, great if you want the same content in different notes and have it all be updated when changing the source. 2. I find myself using emacs for more and more things. Having the power of emacs available is more often a lot more practical and efficient than not. 3. Elisp is less confusing IMO and it’s certainly more powerful. 4. I’m pretty sure emacs can do everything neovim can, but not the other way around. It takes time to learn and configure emacs, so it might be frustrating to use in the beginning, but personally I’m glad I stuck with it.

You can highlight chunks of code you want to revert/stage/apply etc, not just entire files. To me this is the killer feature. It's possible with the cli but a bit unwieldy.

Regular vim has had a Lua interpreter for a long time; & as a proof of concept at least, it's been shown that lua-lpeg based syntax highlighting can be installed in a plugin. Neovim brought in native treesitter, an lsp client, and a detailed remote lua api w/ messagepack messaging built in (the first 2 relatively recently). I think their claim to extensibility is due to the api; & comparisons to emacs tend to have that feature in particular in focus. I think they lag behind emacs with respect to how well integrated that extension ecosystem is. Installing/configuring various IDE-like tools is easier on emacs; and the syntax for the lua api is a little too busy. Recently there's been a number of very annoying breakages in treesitter packages as well. As to remote messaging etc., vanilla vim can do that as well, with arguably a more straightforward interface.

>1. I heard Org mode is pretty good but how does it compare to vimwiki? Don't know. But even as a seasoned Emacs user Org mode feels like a full time job to set up. >2. You can do a lot of computing stuff in emacs like checking emails and stuff, but is it practical / more efficient in emacs than doing it via GUI? No. I've used Rmail, Gnus, and VM and they all required immense amounts of fiddling and couldn't even do IMAP properly. Gnus is arguably the most powerful, but it's extremely fragile too. I was constantly having to delete my local Gnus index and rebuild it. It would often not show emails in my mailboxes that I knew were there. After Emacs's SMTP interface package silently dropped a very important outgoing email I switched to Thunderbird years ago and never looked back. For text mode Alpine is amazing. >3. How does Emacs Lisp compare to vimscript / lua? Elisp is really good, a properly designed programming language. >4. Are there any other features emacs has that neovim does not? Too many to list.

- Orgmode - Org-roam - GUI specific things like rendering SVGs and having font scaling for headers/UI and mixing proportional and monospaced fonts. Edit: Also I think Orderless and the vertico/consult eco system isnfar more powerful than Telescope.nvim.

visual hunks I can see have been a long standing part of the "magic" of magit. as a vim (now neovim) enthusiast, id like to point out that plugins like **vim-fugitive** and **gitsigns.nvim** (and many more) provide feature parity as far as I can tell, and with plugins like **diffview.nvim** , (Neo)vim has a robust ecosystem for git now. I wonder what other "standout" features still remain unique to Magit.

Kindly try searching this subreddit as many have asked very similar questions. You may benefit from similar answers. I came from (Neo)vim and am currently years into using Emacs. I currently use a non-evil configuration. With that context I will answer these questions. 1. Org mode does what Vimwiki can do and so, so much more. With org mode you have a format that you may convert to most all other useful document formats. You may also keep an agenda and a totally customizable todo list. You can render images inline. You can write tables with spreadsheet formulas. You can compose HTML emails with org-mode. You can create an extensive knowledge base with org-roam or denote.el. You can manage your email contacts and have them auto-complete from an org file. You can write your school paper with org-mode and get fancy LaTeX exports. You can organize a cookbook with org-chef. You can practice literate programming by writing it all out in org-mode with code blocks and tangling that single, flat (but highly organized) file into as many separate source files as you might need, edit those source files and tangle those changes back to the org file the source code came from. It goes on and on and on. I am certain there are things I missed, or don't know about. 2. Yes. This especially goes for the heavy org-mode user. You can make direct links to emails and other documents that are related to a particular project/task. 3. Emacs Lisp is its own fully-fledged language. Emacs is its interpreter. It is far beyond vimscript. Now that elisp is compiled to native code, it is more comparable to lua than it ever has been. Lua is still an extension language entirely on its own, however. If you prefer small/sharp tools for use-case scenarios outside of your favorite editor, Lua might seem more desirable. Elisp has far more language features built in, however, many of which are already context/buffer aware in Emacs. Some say elisp is kinda comparable to common lisp, so some of the ideas you may learn in elisp are transferable to any other lispy dialect. 4. Being a graphical program first means that there are many, many features in Emacs that are not even possible in Neovim. To properly answer this question, one must go over 40 years of contributions to Emacs core and to 3rd party packages, scripts and hacks. The biggest advantage Emacs has over Neovim are these numerous and stable contributions.

Was a neovim user for almost 2 years and pretty happy with it. 1. I switched to emacs out if curiosity 2. Org mode and roam, amazing for notes 3. Detachable frames 4. Great terminal integration in comparison to a vim GUI 5. Much better IMO self documentation 6. Much more extensible 7. Prettier 8. Multifont 9. Cleaner and more discoverable config 10. More mature plugins than neovim 11. Amazing Multiproject management 12. Magit for git 13. Daemon 14. SVG

For me the best way to learn Magit was to actually try and use some Magit commands instead of reverting to git in a shell. I'd usually just M-x and type "git rebase" or some other operation I want to do and hopefully search will provide "magit-rebase". (or some other command) Eventually I learned enough keyboard shortcuts and commands to just prefer Magit because it's faster than typing stuff in shell. Then I learned some extra features, that are hard to do in shell and now I can't go back to just using git. I'd add, that Magit really shines if you actually use git "properly". That is, you do well structured commits and try to make the git history and individual commits clean, helpful and descriptive. To do this, you often end up doing things like squashed commits, committing individual hunks in a file and other operations that are pretty complicated to do directly with git, but very easy with Magit. If you just do a bunch of "fix, fix2, tralala, hopefully this works, try 2" commits with no commit message, then Magit can't offer a lot of help over "git commit -a -m fix2".

GUI and full mouse support. I can do everything with VIM keybindings, but when I am pairing with others, lacking mouse access made it that much harder for folks.

I'm not sure about _"standout" features_. I've been an active git user for a decade, I think. Most of it as a professional software developer. And until somewhat over a year ago I mostly used partially Jetbrains IDEs functionality (especially to merge branch conflicts) and partially git CLI. Then I had to switch from Jetbrains IDE to VSCode, but I couldn't get comfortable with version control there, although there are some _very_ good parts in it. Then just about half a year ago I tried magit and now I cannot imagine myself without it. I think it's just that it is right under your fingers. Not sure what you need - hit "?" and look for the available commands. Main status screen provides just the right info for you, it's amazing. Need to get something from a stash - they're right there as well. Look through any of them, pick whatever part you need. Unstaged/staged diffs are there as well. Want to stage a part of a diff - you got it. Want to discard some other part - easy-peasy. Want to see the old version of the file - just hit "enter" on a removed chunk of the diff. Not sure how, but it's so intuitive, it's unbelievable! I didn't learn it, I haven't been used to it - I just started using it and it keeps working whatever I want from it (with just occasional googling maybe). It combines fine-tunement of direct CLI git usage and convenience of the best GUI tools (e.g. from Jetbrains). As far as I remember, the only thing I couldn't get used to with magit is which is head and which is upstream in cherry-picking. It feels redundant and less convenient than with CLI (for the basic case).

Honestly, just curiosity after I watched a video of someone using EXWM. I don't even use evil mode anymore. 1. idk, but org mode is really cool 2. yes - just trust me (I don't do email in emacs though) 3. orders of magnitude better than vimscript, you can do a lot of cool stuff w/ lisp. 4. yes, you kind of have to use it to see why its so nice. Everything is contained in a single environment. I could say things like magit, or org mode, but in reality emacs is whatever you want or need it to be.

I'm neither a big neovim nor emacs power user, so the reason I switched is simple. Emacs is built as a graphical application, which allows mixed fonts and font sizes in different parts of the application (even the same buffer). That's really good for when I'm writing my notes in org-mode compared to vim wiki (e.g. I can make the normal text appear in a serif font and code blocks as monospace and so on).

I still use both (with evil for emacs). Normally neovim from programming since I learned it first and work a lot on ssh connections and emacs for my school notes since org mode is great. Even compared to obsidian, what I was using for notes before, org is crazy powerful. I don't have any experience with vimwiki, but I can't imagine it having any feature that org doesn't, to be honest.

I've switched back and fourth multiple times, but now I'm comfortable with emacs. I started with Vim and got very comfortable. Some where along the way I switched to doom emacs. Doom taught some basics and I got comfortable with it. But the start up time was too much and it felt too much like a Blackbox. So I went back to Vim. When using Vim, I missed two essential features that are baked into emacs like no other editor. (1) the REPL integration and (2) org mode. REPL integration in emacs is best and everything else out there is just a bad imitation. Earlier this year I wanted to learn clojure. After doing some exploring, I found corgi emacs. That's just a thin layer of configuration over emacs with Vi key bindings specialised for clojure development. This has been the sweet spot for me. Learning clojure has also got me more comfortable with elisp. So it feels more natural. Overall I think the REPL integration is the best part about emacs and the language of lisp enables you to think like that. REPL is why I keep going back to emacs.

Use n/p and jumping to sections. Use RET for jumping to code. Take advantage of collapsing sections you use less. Know !! lets you shell out to git. Understand how things like `d r` default to the commit you are viewing and other dwim behavior.

For me, I've switched back and forth but ultimately settled on emacs. Why: - Org mode - just in general - Magit - again in general - Better scripting lang than vim's vimscript (IMO, though this whole list is IMO) - Everything integrated into the editor makes more sense to me than having the editor invoke other things as subprocesses (I know emacs does this sometimes but in vim it's "the way you primarily go about doing things") - Emacs keybindings are easier to replicate into other programs, for example many IDEs have an emacs keybind setup that works perfectly, but the vim one is jank because of how "weird" the vim system is) - essentially, I learn emacs but don't have to do everything through emacs, unlike vim where if you're a vim poweruser trying to use anything else you'll have a hard time - More plugins for things I need - Integrated help system - when I used vim I frequently had to make a sort of thing akin to this - I had a command that would echo my binds just in case I forgot the ones I don't use as often. Forgot one that I didn't make? Whelp, time to pull up the docs for the plugin I'm trying to use. Now I can just do `C-h b` and it lists the bindings I've got, searchable with ivy and related.

[deleted]

[deleted]

> I'd say that as a whole neovim is an attempt of vim community to catch up to Emacs in some ways. I think in the process they opted for a better development model, though: a pull request-based developing flow without copyright assignment. Although I use Emacs, that should be a big point to consider to attract contributors.

Emacs package: keyfreq [https://github.com/dacap/keyfreq](https://github.com/dacap/keyfreq) Real vim ninja counts every keystroke, right? But it isn't easy to achieve in Vim. [https://github.com/vim/vim/issues/6349](https://github.com/vim/vim/issues/6349)

After 8 or 9 years of Emacs, much of that with Doom Emacs specifically, I recently switched in the opposite direction to Neovim with a handmade config. I wrote up a reply to a prompt about what I miss and what I don't miss from Emacs [here](https://reddit.com/r/neovim/comments/z9kg0k/_/iymff2b/?context=1). Some of what I do miss speaks to your questions here, and as a spoiler for #4 Magit does not have any close competition from the Vim ecosystem yet. Other remarks: Neovim's LSP and treesitter are subjectively better, LuaJIT is great, async is great. Never found personal value or enjoyment in Emacs-as-my-everything mindset. Parting shot: don't ask Emacs OR Neovim people about startup time if you want to have a productive convo, lol

The better scripting language part is key for me. Tbh I think I like vim better than emacs as a concept. It makes more sense to me to have a lightweight editor and use other processes for the rest. And there's a reason evil is so popular. But I can't wrap my head around vimscript at all and elisp is ultimately just lisp

Lisp. I preferred vi until I started coding in a Lisp professionaly. That's when Emacs finally stuck with me.

One thing people have touched on that I want to emphasize is that elisp and Lua are worlds apart. Lua exists to be an extension or config language. You are given access to certain api details. Whereas eMacs is… written in elisp! The code base is 300k loc of C and 1.2M loc of elisp. The editor is written in elisp and it goes deep. You are working on a fully integrated programming environment that you can introspect and modify as it runs. It’s comparable to the original smalltalk environments in terms of its power. What this means to me is that emacs is the environment that grows with your forever. Period. No licensing bs, no bloated dependencies (eg: electron). The emacs build depends directly on basic os libraries and that’s it. It’s fairly efficient (now a days!) on ram and cpu vs other environments like vs code and intellij. The philosophy and design of the editor and underlying elisp is so stable and doesn’t change with the flavor of the day coding styles. Emacs is the single piece of software I have used the longest. It’s outlasted everything even including THE SHELL itself. (I’ve started on bash/Linux, csh/sunos, bash/osx and now zsh/osx).

2. Yes. I find E-mailing in Emacs is particularly practical and efficient for dealing with E-mail-based development workflow. Combined with magit, IMO this workflow is more efficient than Github. 3. Emacs Lisp is a powerful language. I hate to say this, since Elisp is NOT a powerful Lisp, but it’s better than many other languages, including Lua (ofc only my own opinion). Elisp is a Lisp, after all. And Emacs is the best IDE for Elisp.

Ah, I stand corrected. I really am out of the loop..

I was sold on Doom Emacs and actually used and got proficient in it after 9 months and felt like home. Felt that I’d never been as successful with vim nor neovim. The thing is that every other update from Doom usually broke something and that impacted my work. So I had to go back to neovim with just a few plugins to avoid breakages which so far haven’t experienced. I even tried distributions like AstroVim which were way more buggy than Doom Emacs. I cannot see how I can depend on these vim/Emacs distros for my work if they constantly break.

I switched because of magit. Amazing git interface

vimscript

Thanks for sharing, Regolith sound like Doom Emacs for Emacs :-) Personally I'm not anymore on Ubuntu because the DE switch was the initial cause but subsequent Ubuntu evolution was and are even worse (for instance snap, an absurd step toward commercial crapware model for no technical reason behind) and being discovered NixOS I've found a good compromise in terms of time spent in and outcome, once I've made a stable config the rest is just pushing it around, nothing to do by hand or automated with third party tools except Emacs itself (NixOS config, tangled from org-mode). I see from the screenshot that Regolith support both tiling and floating model witch might be nice, I do not no if the subsequent apply also to it then: personally I like EXWM in mere WM terms because allow free tiling, I mean: hit-a-key and get a vertical subdivision (`split-window-right`), another an horizontal one (`split-window-below`) so I can fire up anything I want where I want instead of following a "tiling algorithm". I can flip between "last focused" and "current" windows with a single key as well (`mode-line-other-buffer`), maximize (`delete-other-windows`) or moving from a window to another (`other-window`) witch when I fist tried was a bit hard to get, but once I get it awesome, I still have to find something equally fast and comfy, though I imaging some tiling WM have or sooner or later will have something equivalent. Equally for closing with `kill-this-buffer` (kill the current buffer/app but leave the window/the subdivision of the screen) and `kill-buffer-and-window` (kill both), again at first "strange" but thereafter far more quick & comfy than classic windows control like _ ⃞ X in various shape/location/order. That's alone for me was a very positive evolution, the Emacs integration the bonus, so for instance from an org-mode slide a click on a link actually change my windows layout automatically (just an `elisp:` link with a sexp wrapped in a `(progn ...)`), something that might be achievable with xdotools or some WM internal systems, but not as easy as Emacs and not without learning another thing with a limited scope...

Sometimes I though myself to quit EXWM for something else when Emacs casually freeze / have a blocking operation underway, but I still have to find something that approximate my workflow enough or give some better... Windows management à-la-Emacs is unparalleled IMO... Sometimes I have to switch to a virtual console and run alias unlockEmacs="sudo kill -SIGUSR2 `pgrep emacs`" from my zsh (or pretty any Unix shell), but it's still too powerful for me to switch...

Org mode plus it's GNU project

Org-mode. I had a use case (academic job hunt including managing requests for reference letters) where Org was clearly a superior tool, and once I'd gotten used to working with it, I was hooked. I haven't used VimWiki much, but it felt extremely clunky and frustrating compared to the ease and feature richness of Org. VW only had a small subset of Org's functionality, and Carsten Dominik put a lot of thought into simple, logical and context aware navigation and keybindings. I recommend watching his Google Tech Talk from 2008 where he presents Org, it's a good way to understand the intent and design philosophy of it. Also, Magit is great, and I use Mu4E as my daily e-mail work, the best text based mail client I have experienced so far. I use ebib for my bibliography management, org-ref for bibliography integration with Org, and org-roam for my Zettelkasten-ish note system (named for Roam, but closer in experience to Obsidian, really l. I didn't as much switch as expand into Emacs, though - I still prefer my Vim setup for LaTeX, and I'm mainly using Vim for pure Python coding. I have ditched Jupyter in favor of Emacs and Org, though, which is actually where I do most of my Python work (I'm a research scientist, not a software engineer). I'm using Evil-mode with extensions which is actually very close to the Vim experience - down to the leader key, and ports of popular Vim plug-ins. It actually feels a lot like "Vim with superpowers" rather than "true" Emacs at this point.

Yeah, I am the same. I recognize the really nice features magit has, and it's probably the best UI built atop git. But, I am just more comfortable working directly with git in the terminal - the cost of another concept layer/abstraction just isn't worth it for me. I think for a newcomer to git, magit is awesome though.

I switched to spacemacs because vim syntaxhighlight  got stuck on one particular cpp file, I don’t known which cpp syntax cause the problem but I don’t want to spend too much time to find out

1. Org mode is great. I didn't use vimwiki. Actually, mostly I use org mode for my literate config. It can do lots of other things, but most of them are better left to other software. 2. Most non-editing stuff in emacs is bloat, to be avoided. It does several cool things better than vim, like editing remote files (tramp). But they are all editing-related. Emacs is, at the end of the day, an editor, and in my opinion should be used that way. 3. Elisp is much harder to learn, read, and use. It has technical advantages over vimscript and lua, but both of the latter can be learned in a day or so if you have a programming background. And you can edit/understand them pretty much without any study. At no point does elisp become easy to read or use. Maybe if you programmed in it all day every day, but no one does that. 4. Emacs has lots and lots of features that neovim does not. However, 99% of them are things that are better done in other software. For editing, emacs and vim are on par. I have carefully customized both my emacs and vim so they look and feel exactly the same. Most of the time I can't easily tell which I'm using. I really like emacs' client-server model. And its gui is very nice (better than the vim gui by a mile) and customizable. Those are basically the things that keep me in emacs. Emacs is somewhat more tweakable than vim, but the gap is not as large as is made out to be by emacs enthusiasts, and emacs has a great, great many terrible defaults while neovim has far fewer. Surprisingly, emacs' package management is more cumbersome. My init.vim is 487 lines (with lots of comments). My init.el is 963 after tangling, and contains no comments. Vim has far better documentation. Emacs has a lot of "self documenting" features and code, which generally means very poorly written, not as accessible, and harder to get details out of. Basically, you have to understand elisp and read the code to figure out what is going on in many cases. The vim community is also much larger and (no offense to the folks here) more responsive/helpful. Overall, with some heavy customization, the two editors can be very similar. If you don't like to customize, then you should use vim/neovim.

> GNU project Yes! The philosophy of the project hits all the right boxes for me. The incredible built-in help system and inherent introspectability are surface manifestations of that. Also LaTeX support back in the day. I remember shouting and screaming at an olde timey word processor called Ami Pro, fighting in vain to format zoology papers in the computer lab. Some helpful math-type person came over, showed me literal text wizardry at his machine, and set me up for the price of a few beers. Went away for a few years, but now firmly back because of email and orgmode.

PS: I used Vim for 95% of my work for like 7 years before giving Emacs a proper shot, so I'm no life long expert but definitely a fairly seasoned Vim user. And for the question of "is it better to do in Emacs than the GUI": I think that's a highly individual question. For me the question is that some tools are way better like this, some not so much. I still use Firefox for the Web, and prefer Ranger as a file manager or cmus as a music player over anything built in to Emacs. The way I see it, Vim keybindings are a superior way of manipulating text, and Emacs is capable of turning many more tasks into a matter of text manipulation than Vim itself can. So using Emacs allows me to use Vim - the editing philosophy and the keybindings, not the software - for many more tasks than Vim - the software - allows me to. And that makes me happy.

I've had only 2-3 years on emacs, but also on doom and... so much this. - Doom emacs was fast to startup (for a heavy emacs configuration), but pretty slow overall, even on my M1-machines. I have always heard that emacs performance on linux is much much better, but I can't test it and even if – it is of no use to me. - Micro-stutters, performance issues everywhere. In most cases not terribly slow, but always visible. - More then once my config was broken after an update, but again, maybe an issue of doom emacs - too many packages, configs and pinning. - I understand reasons behind gccjit, but my editor compiling something for minutes leaves a sore taste in my mouth. - Magit is cool, but I do not care - lazygit is more than enough for me, and the UI is simpler and prettier. - Org is a good format, but I never bought into the "everything in org"-coolaid - for most things it is a suboptimal solution and I like small, sharp tools more. Even for GTD Omnifocus is technically better - sync is instantaneous, encrypted and mobile clients are full-featured. I give Org points for being text-only, open-source and how you can seamlessly mix some kind of technical outline with a task manager. I do not know how much of all above is due to doom emacs issues and want to try to port my doom config to custom config on emacs@29 over the holidays, using eglot and evil. And on paper I also like emacs more - instant eval, self-documented. I do not like elisp, but lua would also never be my language of choice. But I've tried configuring neovim from scratch for fun and had a working config by the end of the day. LSP works seamlessly, I've even managed to configure DAP for rust and it is so snappy that it is very difficult to go back to emacs. Also, neovim community makes efforts to make configuration easier. E.g. mason is amazing and something similar should exist for emacs. Eli Zaretskii has written, as I remember, that emacs community leans too much on implementing everything in elisp, since it so much easier than hacking the core in C. But elisp is slow and mostly blocking and while there are tremendous efforts in last years to address long-standing performance issues, I have doubts that a performance comparable to neovim can ever be reached. Would like to be proven wrong, since emacs is cool. But so is neovim.

Two decade VIM user here. VIM is an implementation of a great language for editing text. Emacs is a great framework for building applications that edit text. They don't really compete in my opinion. I edit my text in the best application that fits the format of the text. Depending if it's prose, notes, source code, JSON, or a letter to my grandmother, I'll use a different application. I prefer applications that support the VIM language. I use Emacs specifically for storing notes - both personal and professional - because org-mode is by far, bar none, the absolute best note taking application. And as Emacs supports evil-mode for VIM keybindings lets me use it in a familiar, comfortable way.

- GUI support - Neovim and vim didn't seem to be headed towards the improve what exists mindset I value - Emacs lisp interested me - Emacs packages are far superior to most nurses apps and few neovim and vim plugins work well as standalone apps and those that try to are often under baked. - Org Mode - Extensibility - Emacs is generally more cohesive in how extensibility is exposed - multiple frames running on one session is so so nice - Documentation for hackers is top tier

- org-mode and vim wiki are not even comparable. Vim wiki is an ok tool for just wiki work but org-mode is an entire ecosystem and can be used for practically anything - one of the reasons I switched was due to the nurses tools I used being pretty lack luster in some aspects. In this case the biggest one being mutt which I have since replaced with the mu4e emacs package. In general this is all crazy continent and mixes well with tools like org-mode - as someone who got to learn all 3 I can say that they are all capable languages. While I have written lots of vimscript I find elisp substantially more fun to work with. Lua while a nicer language than vimscript and in some ways nicer than elisp is far from as well integrated into the editor and always made working with lua in neovim messy. It's definitely nicer than vimscript but felt like a handycap. - There are lots of features that neovim lacks. Biggest one I use every day is the multiple frame support and emacsclient. Another is interactive shells. Neovim removed this from vim but in emacs this functionality is first class. used all over and is even fully supported for running async commands interactively. Yes you can use the integrated terminal but it's kinda clumsy since you lose all the power your editor was giving you.

I switched because Neovim is fragmenting the Vim ecosystem. Now if a plugin is written in Lua, it is only for Neovim. Bram is BDFL for Vim, and he does things his way, so Neovim was probably a needed change, but now there are 2 vims. Emacs added native compilation of elisp recently, and Doom Emacs is a nice, complete solution.

Had nearly the exact same experience myself.

I think one thing is adding different parts of the same file, I think git add -p is how to do it in command line but it sounds like the magit wizards have a good way to do that. I’ve done it exactly one time though so hopefully with small, contained commits, I never actually need to do “commit surgery”. I’m much more likely to reset and start again from the previous commit if I mess up.

So I cannot speak for vimwiki or the efficiency of programs in emacs vs a GUI, but the MAIN reason that I left vim about 6 or 7 years ago was because I was SO SO tired of trying to program an editor in a language that was never really meant to be anything more than a configuration-specific DSL. Elisp has problems, sure, but it is at least a general purpose programming language. Vimscript is a nightmare. Lua is a fine language, but my attempts st using it for neovim have me feeling like it is attempting to fix the problem the wrong way around there, but I cannot speak on that too deeply. Magit is incredible. Evil is vim with a different underlying language. And elisp is leaps and bounds better than vimscript.

Mainly because it's less limiting. A few particular features finally dragged me over, but really the general idea of emacs, with a real programming language built-in and deeply integrated, almost notoriously extensible and customizable, etc, seemed like a better investment. Vim, by contrast, does get nice things, but it all feels very shoe-horned in to an editor that wasn't really designed for it. That said, I switched many years ago, but if it were today, magit would be the only incentive I need. Once you use magit, anything else is like trying to work with a git repository by banging rocks together.

> I heard Org mode is pretty good but how does it compare to vimwiki? I don't know vimwiki, but org-mode is so powerful and yet simple to use, I have not seen anything close. Org-mode alone might be a motivation for some to learn Emacs basics. But hopefully org format will get more adopted by other editors as well. > You can do a lot of computing stuff in emacs like checking emails and stuff, but is it practical / more efficient in emacs than doing it via GUI? I think it will be hard to beat for example Thunderbird. So I am not investing time in getting e-mails set up in Emacs. > How does Emacs Lisp compare to vimscript / lua? I think Elisp kills Vimscript easily, even while Elisp is not the best programming language itself. But Vimscript is just so shoehorned and weird, that it does not stand a chance. Lua on the other hand is a full blown general purpose language, that seems to have some nice features. I mean people use Lua for other things than editor configuration. Few people use Elisp for other purposes than configuring what Emacs does. Granted, that can be a lot, but I don't think the primary idea of Elisp is general purpose computing. > Are there any other features emacs has that neovim does not? Emacs does many things out of the box, which neovim does not do at all. Things like starting shells inside of Emacs or using tramp to go on servers or inside docker containers. Good handling of lispy languages. For many things there are probably nice plugins for NeoVim, but probably not for all things, because they are outside of the ways people use NeoVim. One wouldn't start a shell inside NeoVim, but instead maybe tmux or exit NeoVim and do things in the terminal, where one started NeoVim. Simply different ways of doing things. Ultimately: Just try things out and learn and see what you like more.

Coming back to emacs. Its easier to use elisp compared to vimscript or Lua. But that is just me.

I guess this explains why I don't get into magit. Most of my uses of git are of the form "git commit -a -m". I'm not doing commits with no messages and going tralala. That's a strawman. I just like the repo history to store the commits that actually happened, rather than the commits I've manufactured to look pretty. And I work on separate branches and set git merge to always create a merge commit, so that if I do want to see a rollup of all the changes for a given feature, just look at the merge commit.

this remind me the time we had xemacs for a while! I wonder if the neovim/vim outcome will end up the same..

That's close to where I am. Not Regolith but using gnome-flashback as a DE with i3, as Regolith does. Definitely seems worthwhile to me over the roll-your-own-DE options. Every now and then something about the desktop I've never needed before *just works*, when if I was on bare-bones i3 I'd be finding a package or writing a script, or more likely, doing without.

The below isn't `magit`, but `vc` which is the generic Version Control part of Emacs itself. The way `git blame` is integrated is absolutely fantastic. In any version controlled file, type `C-x v g` for `vc-annotate` This brings up the annotated file in a new buffer. From here you can navigate in time between versions in a way that is just sooo convenient for some deep archeology. * `p` and `n` -- previous/next revision * `j` -- `vc-annotate-revision-at-line` -- to jump to the revision of the line you're on so you can see what the code looked like at that time * `l` -- `vc-annotate-show-log-revision-at-line` -- Show the commit message for the revision Those commands are a game changer for how you can understand how the code changed. I don't know how many times I've used that to figure out whether it looked like a change was intentional or not, or the thing that introduced a bug. The only minor gripe with it is that it's a different subsystem than magit, so it doesn't interact with magit (where I spend most of the time).

I was trying my hand at learning common lisp, and emacs was recommended.

> Regolith support both tiling and floating model witch might be nice Regolith is just i3 with some polish/config, and i3 has that. i3 is very manual, so you choose the splits and layouts. That is one of the things I like about it over some others. But EXWM does have the benefit of working with one single windowing model rather than two. A separate WM means two models, though with some tweaks you can unify them to some extent. e.g. I use windmove within Emacs but if I hit an edge or am not in an Emacs window, the same keys do the same job in the window manager. It's only one small integration though, not the same. However, that compromise is worth it to me for my window manager to be something separate and rock solid, and then I have one or more more transient Emacs instances. I also want little from my WM as mostly I have a full screen Emacs, a couple of web browsers, and usually not much else.

I looked onto the mess treesitter and LSP configuation in Neovim was, gave Emacs a try, found many more sane defaults and stayed there.

That’s actually what’s held me back - emacs performance on windows has historically been very poor for me. File i/o “the windows way” was always cited as something emacs simply couldn’t overcome… I know you say you don’t use Windows much but if you’ve got any suggestions on where I can look for optimizations, I’d be grateful.

I spent years trying to create a consistent computing environment with vim at its center. Initially I tried following the Unix as your IDE philosophy which didn't work. Then I tried bringing everything into Vim, but that was very limiting, and the Vim community in general (especially back then) was very much against this kind of work. Switched to Emacs because I finally gave up on vimwiki and in less than a month I was able to set up a computing environment that I only dreamed about with Vim. Now the only computing I do that isn't part of this consistent environment are a handful of specific websites (like banking) and unfortunately, Discord.

When I was using i3 it was just a spiral tiling WM, supporting floating windows but a very limited support, nothing else, no free tiling so to speak, perhaps it's evolved now. Personally I was using i3 like you with tabs, a tab for Emacs, another for Firefox and another for a terminal and eventual others X11 apps, still efficient, but not as efficient as free tiling. That was one of the topmost reasons for me to switch though I imaging in 5 years i3 have evolved since tiling still get tractions on many users.

Huh, I didn't realize it had been through that evolution, as it no longer did spirals when I first came to it about 4 years ago. It's very much manual layout. Now if you want to make it spiral you have to add plugin scripts to make that happen. Any of the spiraling WMs I tried didn't last long - I can't deal with that sort of rigidity.

I loved the idea of using Emacs as my sole frontend for the OS, and that you could program it in Lisp instead of Visual Basic or some shit like that!

Glad to know, that was essentially the most compelling reason for me to choose EXWM, now I'm very comfy in Emacs, but back then I was not much and I tried EXWM just to get free tiling, without having to learn Haskell (Awesome) or tweaks too much (Herbstluftwm) or having too poor floating windows support for mere dialogs and so on... Evidently I was not alone if now surviving WM are not rigid anymore :D

Yeah apologies if that feelt a bit judgmental, I just wanted to get my point across. The example was somewhat extreme. You do whatever makes sense for you. I'm just saying, that Magit really shines when you use git to its fullest. It can drive the workflow really well. If you stick to basics, git already does great job, because it's great tool. I still think you might want to try and just force yourself to use the Magit commands for a while to see if it sticks. The interface is very good and once you learn the shortcuts, it can do a great job and will save you from switching to terminal just for git. As for the commits that happened vs manufactured to look pretty, I was just referring to cases where I need to make two technically unrelated changes (good old yak shaving) and I want to commit them separately even though the change is in the same file. (For example reformatting the code without changes in functionality committed separately before making change to the actual logic to make the PR review easier)

And I'm sorry I overreacted. I get frustrated with git, because it's a de facto standard, and it's flexible enough that I can use it basically the way I'd like to, but the community consensus around it is so backwards from what I'd prefer. [This writeup](https://www.fossil-scm.org/home/doc/trunk/www/fossil-v-git.wiki#history) is a better exposition of what I meant by "manufactured" and what I wish I was using than I could write myself. Selecting individual chunks to stage is cool. I've nothing against it, it doesn't change any history.

I switched from Vim to Emacs before VS Code existed and while Neovim was still in its infancy. I was looking for a cross-platform editor (preferably one that worked in a TTY) with IDE features such as syntax-based folding, go-to-definition, reference lookup, code completion, docstring popups, and visual debugging. Vim had all of that at the time, but it was a lot easier to get it working in Emacs. Now one could make an argument that it is easier to get that stuff working in Neovim than in Emacs. That said, Emacs still offers many advantages over Neovim or any other editor, including Org (personal organization, technical docs, literate programming), Magit (git user interface), and Elisp (editor configuration). And most important of all, the Emacs community is amazingly supportive, thoughtful, and intelligent. I won't go into details, but I will say that the deeper you get into the communities of Emacs and other editors, you will most likely enjoy your interactions with Emacs folks the most.

I think eventually, when you accumulate enough changes from the base configuration of any of the Emacs distros, you need to make the effort to move to GNU Emacs. I find amazing that the configurations for Emacs are as backwards compatible as they are. Emacs is Lisp code. Many hundreds of thousands of lines of code of a very dynamic language, used idiomatically in very dynamic ways, and yet, things are kept maintainable through decades. Aren't large dynamic projects supposed to fail? And yet... Usually when my configuration does break on an update, it's something very reasonable, a place where I changed code or advised something to customize things in a way not exactly supported by upstream, and it's easy to fix. All that said, the Emacs distros make a lot of configurations on top of the base config, and they enable a lot of third party packages that themselves may update at different schedules. Then you add your own configurations on top of all those and yeah, eventually it might grow unstable. When you've got used to Emacs and decided the effort will pay off, do try to move to vanilla.

I didn't tinker with emacs or vim on Windows too much because I always felt like they were, understandably, second class citizens. I just treated emacs with evil mode as Window's best version of vim. Getting built-ins like dired or shell working on Windows was a headache that ended with using a tool that was built with Windows in mind.

Yeah, I'm also not a huge fan of rewriting commit history. Especially stuff like "squash and merge". But I prefer to not leave "fixed typo" commits in before submitting change for PR, because that history is IMO not useful and for example in "git blame" output (BTW another thing that Magit does well) it just makes me go one commit deeper to actually figure out why actual logical change was made.

It really depends on the reasons for the split. I am not sure what it was that made XEmacs happen, but I have a feeling it was because they wanted some specific features in which RMS thought were at odds with the GNU principles. For Vim vs. Neovim, it is more a problem of governance; Bram still seems to view Vim as "his", to the extent that when asked what the community could do to secure the long-term survival of Vim, he famously replied "keep me alive!". I seriously hope there will be some kind of resolution, but not sure what it will be (I still love (n)Vim and use it daily alongside Emacs).

True, you might have to go a commit deeper. I'm haunted by past experiences maintaining a project that used Clearcase. You couldn't even get a consistent view of the repository at a point in time. Literally impossible. It's a file based version control system, every file has its own individual history, and so you commit every file individually. The only way to know 2 files were modified in a related way was to look at their individual histories, check the timestamps and authors, and guess they were the same if they got committed by the same person just a few seconds apart. Any command would take at least a couple seconds to run, so good luck trying to automate that across a whole codebase... Of course we had a practice in our team to put JIRA tickets in the commit messages of every file, and then list every file we modified related to the ticket in its description... But there was a lot of code we didn't write. After that it doesn't even register to me as a nuisance having to go a commit or two deeper. But you're right. Life should be easier :D and git is great.

I like vc-annotate (probably because long ago I wrote the color scaling code for it). But recently I discovered magit has its own separate blame system: C-c M-g b. Then when you're in blame mode, use Ret on a line to visit the commit diff (at exactly the right place), or b to visit the file version as it was in that commit. In those older commit (blob) file buffers (which are also in blame mode), you can try r and f to see something unique: information about the commit that *removed* a given line, or information about the *last commit* which still *had* a given line. This allows you to blame a commit for having removed a line you still need. It's really impressive (as you'd expect). I just wish it had nice colors (started a [discussion](https://github.com/magit/magit/discussions/4830)).

Yeah, git add -p is my usual work flow. However sometimes I have needed to go more granular than the "split" option gives me, and thats where I have jumped into magit.