Can you settle this for me once and for all? What can emacs do that neovim+plugins can't?

I know it's a question as old as time but I've never used either and I've been reading other posts on this and I'm still pretty fuzzy. I understand the main complaint about emacs from vimmers is that it's too slow and not quite as responsive as vim, whereas the apparent advantage of emacs is that it's "more" than just an editor and this is where I get lost. I've read that emacs has integrated email, browser, calendar, calculator... games? I mean, honest question - who cares? No, really, I'm curious; perhaps there's an answer I'm just not aware of. How often do you use the cal, calc, and email apps in emacs in your workflow. Then as far as more killer emacs apps like Magit, to borrow a phrase, "there's an ~~app:~~ plugin for that" in neovim: [https://github.com/TimUntersberger/neogit](https://github.com/TimUntersberger/neogit) **What functionality does emacs offer that simply can't be implemented as a neovim plugin?** Or perhaps that can't be implemented *nearly* as nicely? Thanks, and sorry for the nth emacs v. vim question that I'm sure you're all sick of.

Use the editor you prefer. If you think vim is better, use it. Generally I like Emacs, but it’s a big world. You do you.

Due to the Turing tarpit, the answer is there is nothing Emacs can do that can't be done by vim+extensions or vscode+extensions. Emacs is a lisp runtime that also implements various editors and just like a lisp machine it contains heavy introspection capabilities. If you think that is cool, you use it. If you just want some feature X it Y that has its origin in the lisp world (because having such a breeding ground helps to generato those kinds of features) you just wait until someone copies it to the environment you like to use.

Ok but, can you tell me what functionality emacs offers that can't be implemented as a neovim plugin?

>lisp machine it contains heavy introspection capabilities. Ok, this is another thing I've been reading about that emacs can do that \[neo\]vim can't. Can you give me like a super brief overview of what this means? What can you do with those capabilities?

To grok the idea, I would suggest you play around with Smalltalk. In a way it has superior introspection capabilities. The distinction between being inside a Smalltalk image vs inside Emacs is however visually easier to see. A modern Smalltalk would be Pharo. The tutorials should very quickly get you towards introspection and changing the running system, because that's it's thing.

Turing equivalent extensions in either system can do anything a program can do. You can also accomplish any programming task you can name in Fortran or machine language. If you really prefer Fortran I can’t name a thing that can’t be done if Fortran that you can do in (say) Haskell. Pick what you like.

In theory, all Turing equivalent systems are equal. Use the thing you like.

There's probably literally nothing that "cannot be implemented as a neovim plugin" The question is: 1) what is actually available and 2) how customizeable what is available is and 3) how easy is to build on top of what is available. If you don't miss anything in vim then you don't need to look further. If you miss something and the investment of switching editor is justifiable than you can consider Emacs (or, frankly these days vscode) In general, Emacs people don't have a clue of what is available in neovim, so we cannot answer your question. I think org-mode, org-roam, magit and auctex are pretty cool, but I have no idea what is available in neovim close to them. I don't normally go around looking for what other editors have but only for how I can make Emacs do what I need. And you know why? I started using emacs in 1990 when neovim was not a thing and I'm still using it today. Most likely I'll be using it when neovim will not be a thing. ​ >I mean, honest question - who cares? If you don't care, there's literally nothing we can say. No matter what we offer, it will be "who cares?" or "neovim has it too".

The argument that [Emacs is not as responsive as vim seems to be true](https://pavelfatin.com/typing-with-pleasure/) but I doubt that anybody is able to recognize this in a real world scenario without too many add-ons (for both). Hyped IDEs are even worse in responsiveness and nobody does seem to care at all. Related to your question what vim can't accomplish where Emacs is shining: I don't know where to begin. Short answer: maybe [everything I blog about Emacs](https://karl-voit.at/tags/emacs/) is not possible with vim+addons. But that doesn't matter because they are two completely different things. While vim is a good editor (I use it on a daily basis), Emacs is an Elisp platform that comes with editor functionality but offers a whole universe. Therefore: this [vim vs. Emacs is completely pointless](https://karl-voit.at/2015/10/23/Emacs-is-not-just-an-editor/). *Ceterum autem censeo* [*don't contribute anything relevant in web forums like Reddit only*](https://karl-voit.at/2020/10/23/avoid-web-forums)

Great, so your example of comparing one language to another gives me the opportunity to clarify my question. If someone were to write a reddit post asking "what can [BQN](https://mlochbaum.github.io/BQN/) do that Haskell can't?" then one thing that I can say is that "while both are turing complete languages and one *can* implement anything the other can, in Haskell you have a *very* strong type system that bqn simply does. not. have, which allows for (a) self-documenting code, (b) easy refactoring, and (c) easy future proofing and debugging... meanwhile BQN allows for *orders of magnitude* more concise source code that is *simply impossible* in Haskell. You can write a program in bqn in 15 lines that would take 200 in Haskell" Now, I've read many times that emacs allows for "introspection" which is extremely difficult if not impossible in vim. Can you give me a concrete example of this?

>If you don't care But I didn't say I don't care. This is why I very specifically said "honest question" and "no really, I'm curious", because I knew that otherwise someone would interpret the question as rhetorical and snarky.

Two things emacs offers me that NeoVim doesn’t as far as I know. Non-modal editing and Org mode. Vi was the main editor available to me from 1992 to at least 1997. I gave it fair shot and I can’t stand modal editing. Still I didn’t go to emacs for about 20 years after I got to abandon vi. I tried it a few times but it wasn’t worth learning for me. What changed it was after I had been burned by OneNote’s proprietary bullshit and was looking for the plaintext free software solution to note taking. I discovered Org. Tried it out. It made learning emacs worth it for me. I can take notes fast. I’m not concerned I will need to convert my file formats one day when the software is suddenly crippled or discontinued. For others it’s something else. For you maybe it’s nothing. Most of us don’t care if you use emacs. Tell us what motives you to care. Then if you respond back “who cares” we will know you’re a troll. If it’s fear of missing out, just try to let that go. You will miss out on nearly everything. Enjoy what you’re doing.

I think you’re asking the wrong question. If you’re dissatisfied with what you use now or curious about alternative ways of working, try other things, it will be much more enlightening than asking for abstract explanations of things that are better experienced. It’s possible to produce completely coherent explanations of the distinctions of course but they’re not enlightening the way trying things yourself is. If you’re happy and productive and not particularly curious, I’m not sure you should bother in the first place. These are development tools, not cancer treatments. You’re not going to live or die on your choice.

Nice cat photo. What does murli mean?

Ok fair enough. Do you happen to know how emacs org mode stacks up against the nvim org-mode equivalent plugins? * [https://github.com/nvim-orgmode/orgmode](https://github.com/nvim-orgmode/orgmode) * https://github.com/nvim-neorg/neorg

You are asking what you can do with access to a programming language... Mainly, write programs. I'm not sure what you're asking.

You said that 'who cares?' is an honest question. Which strongly implies you don't care. No matter how much 'I'm curious' you put around it, it still remains a rhetorical question. And your original question is unanswerable other than with a generic and useless "everything can be implemented as a neovim plugin". So, there you have your answer and I'm done wasting my time. Really, whether you use neovim or Emacs -- honest question -- who cares?

Haha. You ever seen the movie [The Game (1997)](https://www.imdb.com/title/tt0119174/)? Remember [that scene](https://www.youtube.com/watch?v=aL-saxO-Xrs&ab_channel=Charles%27FavMovieClips) where michael douglas asks two times with two different people "what is the game?" and can't get a straight answer? What I'm curious about is why no one can give me a concrete example of how "introspection" can be used in emacs, or what that means. Do I need to make a separate post for this? Is it some secret that only people in the emacs club can know about?

I don’t. I’ve read some opinions of others that it is incomplete. I can’t say if it’s true. For me the absolute killer feature is the key bindings for reordering and changing hierarchy of headings and list items. Looking briefly at the links you provided doesn’t address that. Org was created in Emacs and doesn’t have a good specification so anything else is an approximation limited by the creator’s effort. If note taking is an important use case for you I’d try the neovim plugin and see if it meets your need. If it does, don’t worry, if it doesn’t try it in emacs.

I think you're asking the wrong question (assuming you're serious and not trolling the sub). In terms of handling languages, LSP and similar make choice of editor largely a pure matter of taste. And both Emacs and Neovim have very healthy developer ecosystems with lots of packages/libraries being developed. And as everyone else has pointed out, there is no in principle reason to think that one group is going to be able to develop some library that the other cannot. And modal vs. non-modal shouldn't be a reason since evil and the various other modal packages available for Emacs do all or most of the things one might want from a modal editor. So you would be better off asking different questions. These include: 1. Do you need something other than simply a text editor? 2. Do you primarily work on remote machines with low memory where issues like latency are super important? 3. Do you prefer writing in lua or in lisp? (this seems extremely important -- part of the reason I left vim was that I hated vimscript, and at the time neovim was too young for me to be confident that it would take off properly) 4. Do you see yourself spending any non trivial amount of time tweaking your setup and developing libraries/packages, or are you mostly just going to use whatever is out there? 5. Do you enjoy doing things like inspecting the code that you are running (and possibly modifying it on the fly) or is this something that never or rarely occurs to you?

That's a common name for cats in the German language. I don't think it means anything at all.

You got directions on how to find out what introspection is. You could do some leg work if you were genuinely interested. As you brought up typing up-thread, then you may also be familiar with duck typing. Right now you quack like a troll, that allegedly doesn't use either emacs nor neovim but is somehow still curious about the differences for reasons. You receive replies like a troll would, even if you try the inquisitive variant and "just asking question" playbook. But here. A genuine reply to your question: The qualia of using a self-documenting high introspection environment is not something that is easily conveyed in a reddit comment. And given that you don't care enough to do any kind of leg work, even when directed, I'm surprised you're getting as many replies as you did.

It’s not a secret. But you’re expecting that people are going to be able to summarize an intangible experience well in a few sentences, and a lot of both programming and programming environments is deeply subjective to begin with. Either try it or don’t. I doubt you’ll come to harm or enlightenment either way. It’s a text editor a lot of us fanatically love but there are others. If someone tells you they love listening to Leonard Cohen, is a long explanation of Cohen’s music going to be of help or would you be better off just listening to an album? If you never listen to an album is it really going to hurt you? Is it wrong that you prefer Bob Dylan? We like emacs. We like using it, it works well for us. We like the features. Try it if you’re curious or dissatisfied. Use neovim if you aren’t. It’s fine. Relax. Read a good book. Chill with friends. Take a nice walk. Spend less time worrying about why you should or shouldn’t try a text editor.

Emacs is written in Emacs Lisp, and - as a user - you are given full access to all of that. That means that you can change how Emacs works, and since it is a Lisp, you can change everything at runtime. This is unlike all other editors/environments where what you can do with scripting/configuration is determined by the programmer who wrote the scripting API. Emacs simply gives you access to it all, giving you the power to change it all, either by yourself, or by an Emacs package. The scripting/configuration language is the same as the language Emacs is written in (bar a small core written in C (more or less))

Emacs is it's own Window manager. [exwm](https://drive.google.com/file/d/1C92KYwrzB4yeaehlHLfGUkiNUbiIclVR/view?usp=drivesdk)

Does NeoVim have an API determining what you can access in the editor? If so then it's different from emacs, because in emacs you can modify any part of the editor, you can access everything. So NeoVim plugins using the plugin api can only do what the api allows them. Emacs plugins have the whole editor at their disposal, there is no api.

emacs also has an API. There are functions in elisp that are implemented in C that do magic that cannot be done in elisp itself. None of this really matters in the end.

I agree that the "slowness of emacs" is a non-issue if you have a halfway-decent CPU. I am using a laptop that cost $2000 when it was new four years ago, so, a pretty decent CPU I guess. Unless something is going wrong, every thing I've ever done on emacs has been pretty immediate. Including a consult/affe/orderless utility that uses fd to get a list of every single file on my computer, and narrow the list live as I type regular expressions to match the paths. I am always amazed how I can't detect any delay in the list-narrowing. And this isn't using native-compiled elisp.

That's actually a fantastic point, thank you!

For me, since there are probably countless reasons depending on who you ask: + Emacs allow me to implement my own editing model, which is non-modal. I'm still pretty fast with vim after 5 years with it, and still occasionally use an other modal editor - Kakoune, but unfortunately I've fallen out of love with modal editing. Learning key binds and new way of editing was never a problem for me, so I enjoy making and finding "the best way", which is still evolving. + The ability to implement a multiple-cursors experience which includes the goods from sublime + kakoune + a bunch of things I wanted personally. + The ability to slightly change how a package/plugin works by evaluating elisp, at run time, without closing Emacs. The annoying feelings of plugins that only works 80% how I wanted is just no longer there. + It's dramatically changed the way I work, spending a few minutes writing an elisp snippet to aid what I currently am working on has become a daily phenomenon. Neovim's speed is quite tempting, I'll admit that, but the above is practically impossible with it (unless you plan to write a lisp machine in lua). That's why my "emacs" script would open Kakoune (it's even faster than neovim) instead if it detects a 1% problematic file that would slow emacs down. Trying to do achieve all of the above for any other editor is basically impossible. For neovim, it at max could probably achieve maybe 30% of these requirements (without writing an Emacs clone with lua), and still I would probably need to spend a few months not getting any work done just to reach that 30%. I'd rather be forking Kakoune or Helix at that point.

I've used both relativity extensively and here is what I think the differences are. If you want the latest and flashiest things, neovim and the neovim community in general is much quicker to adopt new technologies(Emacs ain't that far behind though). Neovim/Vim in general is also faster, but to be frank it is negligible. With Emacs, the main benefits are the lisp ecosystem and the way help is really accessible. The level of customisibility that having elisp throughout the editor gives you cannot be matched by neovim. It is just so easy to write a bit of elisp to do things that you end up automating a lot of things. (But also, elisp is not for everyone) Another pattern I have seen is that in general Emacs has a lot more mature plugins and most of them are way more customisible that neovim plugins. Yet another plus for Emacs is that it has an official GUI which can do a lot more like proportional fonts or images which neovim in a terminal cannot do. Neovim also has GUI implementations, but they are not as well integrated as most plugin authors don't take the possibility of GUI being available into consideration. There are also a lot of plugins like notmuch or elfeed while not impossible to create in neovim has no good alternatives. But then again, neovim plays much nicer with the shell when compared to emacs that you can use external tools for those though you will miss out on common keybinding, workflow etc. Now if we really want to get to things that neovim cannot do, Emacs can embed graphical applications or even be your window manager.

Most people in an emacs forum have already evaluated emacs vs others and decided emacs is best suited for their needs. Therefore asking the question on the emacs forum will result in an emacs bias, asking the same question in a neovim forum will have the same effect but will lean towards neovim... Etc etc.. Go ask about emacs vs vscode in the vscode forum or even ask about gnu/Linux/windows/mac/bsd etc. compared to each other in each of those specific forums and you will get similar results. I think the only way is for one to try and approach each and see what clicks for you. For Me it was Vim, not neovim or gvim or even vscode or emacs etc., because I could find more begginer friendly info and resources for good old vim and that's what persuaded me(practical vim, learn vimscript the hard way, learning the vi and vim editors) . However I am Still on these emacs and neovim forums because as soon as I find vim is irritating me for some reason(i. E. the more advanced users/gurus on forums seem to expect one to be highly technical etc.. may just push me away) , I may just jump elsewhere completely or only for that specific something/s.. I must also keep emacs in mind because I want to learn lisp(common lisp)and as I understand emacs is the best suited for lisp use... after that, well perhaps elisp will be more sensible then vimsvript? Who knows. Bottom line is that, if there was really an undeniable solution, noone would be asking such questions because everyone would be using that solution. I know it's tuff for some of us to decide, but its tuffer when you ask these questions and get a zillion different opinions, of which all will be correct and still make good sense in the context of a specific user or group of users.

I’m a neovim user but I’ve dabbled a bit with emacs. More knowledgeable folks can let me know if I’m missing something but basically, for any given function emacs uses (even core ones), you can jump to its definition to understand it and you can possibly overwrite it. In comparison, in neovim you simply cannot override `:cd` and if you want to know what it does you can only refer to the help command

I'm gonna try to answer the "who cares" question as a real question. Most people don't want to use a browser inside of emacs. But a few people do. Maybe because they can tweak it to their liking using lisp, and have the same user interface for the browser that they use for the rest of emacs, which they spend a lot of time customizing and learning. Most people don't use email inside of emacs, but many do. Maybe because it's really easy to do things like, add a link to an email in an org file, or write little scripts to automate certain email tasks. And again, because the user interface is like the rest of emacs. I haven't heard of anyone spending a lot of time with the games, but who knows. They are more of a meme/easter egg kinda thing. Just as a way of showing that emacs comes with everything. I don't use the calculator or calendar but a lot of people do. The nice thing about having this stuff within emacs is that it is easy to link it up with other things you do. Like, you can quickly add time stamps into where you're typing. Or add a time stamp for next wednesday if you need to give yourself a deadline for something. The calculator, I don't know what the strengths are, but a lot of people love it.

There is no API in the sense that you are not limited in what you can access. You can override any functions, including core editor functions if you want to.

Aha! Alright, thank you for answering that one! Makes perfect sense. That's all I was looking for.

10 minutes on Google and you would probably understand already.

Nice, appreciate the answer on that one, thank you. I guess my one concern is, does having all of these things that are only for a niche userbase make the platform "heavier" and contribute to it being slightly slower than nvim, or is that caused by something else?

dam - emacs dudes are mean :P

I mean, to *me*, the main difference is that Emacs includes a decent editor, while vim and neovim do not! (And yes, I've used vi-likes enough to know their tricks.) But I realize that may not be a universally shared opinion. :) I think the clue is really in the fact that people have *bothered* to make all those things like web browsers and games for Emacs! It's because is *easy and fun* to extend! It's an editor and an *application framework*. (One might even say that it's an application framework that *includes* an editor as its default sample app.) And Lisp, despite its learning curve, is a powerful and elegant language once you wrap your mind around it. I've written a small (and not very good) game in Emacs. I never would have bothered doing the same in vim or neovim (even if I *did* like them), because they simply don't include the functionality that made writing my game easy and fun. It would have been just as easy to make my game *standalone* as to write it for (neo)vim.

> I've read that emacs has integrated email, browser, calendar, calculator... games? I mean, honest question - who cares? No, really, I'm curious; perhaps there's an answer I'm just not aware of. How often do you use the cal, calc, and email apps in emacs in your workflow. I use cal every day, calc i don't use because I usually just use M-x eval-expression (+ 1 2 3 4) RET. External email apps or email in browser, i've used in the past but they aren't as convenient when you live or want to live in emacs. So why use emacs for everything? - A uniform interface for everything helps me stay in flow state - Minimal effort to extend any part of my workflow emacs has subsumed - The big one, being able to connect parts of my workflow to others that exist in emacs (ex. Link to email in mu4e I did an org-capture from) Another example of the last is the other day I did an org capture in a remote dired buffer for a task to "pick out pictures to send Tom". So when that comes up in my org agenda as a next item, I open the link to that folder and start browsing. Then I can mark the photos to send and execute my function to open M-x compose with those attached, and all thats left is typing the email. I've eliminated all the busy work in between, it's 100% only things I need to do. You can get close to eliminating all busy work and preserving the feeling of flow with emacs more easily in my experience. Plus, since culturally all emacs users try to move everything into emacs more than other editors there is typically less work to do. Another anecdote is that I had a pomodoro Timer I was using an emacs but wasn't following. My solution was to save my window layout with winner mode and pop up a buffer that said in large font to take a break. Then when the break was over my window layout got restored. The key here is that this took a function and hook of less than four or five lines of code and less than 10 minutes. Say I wanted to reward myself sometimes randomly with a game of Tetris in emacs or something, I could easily add that as well.

>the main difference is that Emacs includes a decent editor, while vim and neovim do not! (And yes, I've used vi-likes enough to know their tricks.) But I realize that may not be a universally shared opinion. :) This is really interesting because, as you say, you usually hear the opposite. Can you expand on this? What makes you say emacs has a decent editor but neovim isn't?

> What I'm curious about is why no one can give me a concrete example of how "introspection" can be used in emacs, or what that means. If you're in the mindset of being able to quickly extend your system, then you'll want to understand it quickly. Introspection in a culture of documentation to make it self documenting editor makes a huge difference in making it possible to quickly do something or writing it off as probably not worth doing. All of those little extra things you were able to do because of those conveniences start to add up and eventually become a huge difference. If you've ever heard of habitability, one may say that Emacs is an extremely habitable environment.

>A uniform interface for everything helps me stay in flow state Super underrated. Thank you for sharing!

Got it, thank you! This helps.

You’re welcome!

I am surprised to see so many patient answers here for the kind of irritating questions being posed by the OP and the entitled way in which he demands feature comparisons based on superficial reading from which he doesn’t seem to have absorbed or tried much. OP - If you are curious - ‘try it and see’. Experience the damn editor or IDE or whatever for yourself And then let us know if the question can be “settled once for all” or is meaningless as Karl Voit has mentioned. For one thing if you actually Read the posts by people living in Emacs or this subreddit, they would have usually explained what they perceive as the benefits of being able to read mail, RSS and having a calendar in Emacs etc.

Nah, that's just stating fact. Though, admittedly, I do feel quite curious about your decision on waiting for an answer on reddit when the same keyword on Google works wonder. :P

Yes, think of Emacs as an IDE for itself, in the Lisp tradition. Most functionality of the editor is written in lisp, which tends to make it “hacker friendly”.

[deleted]

Dude, here's the emacs wiki page on introspection * [https://www.emacswiki.org/emacs/EmacsLispIntrospection](https://www.emacswiki.org/emacs/EmacsLispIntrospection) I'm supposed to understand what it means based on that?

It doesn't make emacs slower to include all of that stuff, because it isn't loaded into memory until it's used. And as far as the hard drive space used, I'm sure emacs is bigger than neovim, but rhetorically, who cares? Giant hard drives are very cheap these days.

Another workflow I'm trying to fully port over his code reviews on GitHub. Old: 1. Alt tab out of my comfortable, familiar, confident emacs world to the browser without my keybindings, hear "You have no power here!" Internally. 2. Go to github.com/notifications 3. See a code review, navigate to it, read description, skim commits, go to the file changes 4. Make detailed comment, get response "I tried that, it's not possible" 5. Copy paste branch name, switch to emacs, go to magit for project, start compiling 6. Find file by name with consult-find, RET, go to line I remember above PR comment 6. Wait for compile 7. Try thing, it compiled and worked. 8. Switch to magit, copy diff 9. alt tab back to respond 10. Create diff code block, paste diff 11. Use arrows or mouse to get to end of code block, hit RET twice 12. Write response New: 1. Hit keybind for [gh-notify](https://github.com/anticomputer/gh-notify) 2. See code review, C-x r (github-review-forge-pr-at-point) (In the background, PR checked out, compile started) 3. read description, skim commits, go to the file changes 4. Make detailed comment, get response "I tried that, it's not possible" 5. Hit Ctrl-p from comment up into diff in [code-review](https://github.com/wandersoncferreira/code-review), hit RET to go directly to real file in correct place (feature not yet implemented) 6. Try thing, it compiled and worked. 7. Go back to code-review buffer 8. Type `diffP` and hit TAB for yasnippet to expand a markdown diff block that automatically inserts copied text, TAB to end up 2 lines under code block 9. write response Comparing the two, one is 3 steps less but that isn't the most important part. Most important for me is: - Not having to wait for a compile or having the resistance of waiting for a compile to test a PR locally - Not having to think about navigating to the same context locally or switching contexts from "web code review" to "local code review" - Not having suspend thinking about my respinse to type ```Ctrl-v```<end><enter><enter>, instead only having to mindlessly type `diffP<tab>` before responding - Having had all this happen in my emacs with my theme, my font, with org-capture available if I have an idea or distraction the whole time

>there is nothing Emacs can do that can't be done by vim+extensions Well, displaying variable-pitch text and generally differently styled text in the same buffer to name one thing or displaying images inside a buffer to name another. The use of vim as a WYSiWYM writing tool suffers massively due to it being restricted to the terminal. I don't know how possible these things are in vscode. ...Unless you also include modifications to vim's C-source in that Turing tarpit, but it would have to be close to a full rewrite to get it to the point where emacs already is.

As an outliner and writing tool (using org-mode) emacs is vastly superior to vim because Emacs is not limited by the terminal. For example you can have variable-pitch fonts and monospace fonts in the same buffer/document or display inline image links in org or markdown. So even if neovim org-mode was 100% feature complete (which is very unlikely to ever be the case) it would still look and feel worse and waste more space with less readability than writing on emacs.

Two reasons, org-mode and scripting. If you write scripts a lot and you'd like to write scripts also for your text editing or ruling a quick user interface with nice interactivity ou tof the box and don't want to reinvent all if that in Lua python or Satan saves us vim script maybe emacs lisp is a nice thing to learn. Anyways I'm happy I learned both, sometimes I use vim to do some editing and sometimes emacs.

I use eglot mode heavily at work. It *just works*. It's an LSP server mode that I use with clangd for c++code. (not lisp server, it's the remote compiler editor support protocol) I was trying to evangelize the use of clangd and the various editors everyone uses at the office. Someone helped me get a neovim solution and it was just dog slow. And the fractured ecosystem about getting an LSP server installed (referenced the clangd website) I got the impression that these modules simply aren't battle tested, or else not widely used/maintained, or else there's some architectural problem that makes it slow. Meanwhile native code compilation for packages has arrived in emacs. Don't get me wrong, watching gray beard wizards zip around in vim was the first time I realized that I needed to get serious about learning better coding workflows and tools. I was used to visual studio and all the pretty things that gave you meanwhile this guy is just going gangbusters on his code in a no-frills terminal. But I landed on emacs instead.

It’s still an API, just a very rich one.

>Do you happen to know how emacs org mode stacks up against the nvim org-mode equivalent plugins? > >What functionality does emacs offer that simply can't be implemented as a neovim plugin? FYI, there was a [post](https://blog.tecosaur.com/tmio/2022-02-30-orgnvim.html) by [nvim-orgmode](https://github.com/nvim-orgmode/orgmode) author, which also mentioned Neovim [blockers](https://github.com/nvim-orgmode/orgmode/issues?q=is%3Aissue+is%3Aopen+sort%3Aupdated-desc+label%3Aneovim-dependency) for some features.

At anytime, you can ask Emacs, what function (and its detailed implementation) is behind a key press. At anytime you can have a look at the current state of a variable (hook, constant, structure, key binding, menu entry), and you can change its value. At anytime, you can redefine how a function is implemented, and you can step through it, and changing its inner states while doing so. And all this without restarting Emacs or without needing to start it in a special mode. It is amazing and hard to explain, you have to experience it.

Seems pretty valuable, thank you. In FP like Haskell I think this is called [referential transparency](https://en.wikipedia.org/wiki/Referential_transparency). I didn't realize introspectability was the same concept but that makes sense.

> I mean, honest question - who cares? No, really, I'm curious; perhaps there's an answer I'm just not aware of. I think the thing you are unaware of is that it is perfectly OK if you don't like using those things and it is also perfectly OK if someone else does. > How often do you use the cal, calc, and email apps in emacs in your workflow. I use Gnus to read my email every day. I bet some people never read their email in Emacs but those who do for the most part check it every day (that's normal, right, reading email every day? —I thought this was a weird question). I also use the calendar every day, mostly when answering emails to schedule things. I think I use calc less often, maybe every other day, but it's not because I use some *other* calculator more often it's just that I don't need a calculator most of the time. > I understand the main complaint about emacs from vimmers is that it's too slow and not quite as responsive as vim This depends very heavily on what you are doing. It happened the other way around to me: I switched *from* Vim *to* Emacs because Vim was so slow that it *lagged behind my typing* and I am not a fast typist. It only happened in LaTeX files, and is a well-known problem in Vim, there is even a section of the manual dedicated to the problem: see `:help tex-slow`. I tried all the tricks in the manual and the only thing that fixed it was turning off syntax highlighting. After a while I decided I missed the colors, tried Emacs which is perfectly snappy (just like Vim was perefectly snappy with every other file type I tried, the problem was just LaTeX), and never looked back. > What functionality does emacs offer that simply can't be implemented as a neovim plugin? Probably nothing, just like there is nothing in Neovim that can't be implemented as an Emacs plugin. Try them both and see which one suits you best.

I use emacs gnus for email... well I stopped for a while after migrating to a new computer a few years ago, but just got it set up again. The reason why is that reading and writing emails is all about navigating text, and personally I have found emacs keybinds to be the most pleasant way to do that. I imagine if I used email more intensively than I do, this would probably be even more important. I think _whether_ the keybinds click with you will largely be a matter of personal preference, I know that a lot of people dislike them (though I suspect most people who feel this way have not actually tried them).

Multiple windows open of the same editor instance; daemon mode; reading man pages/docs/etc in variable width font; easily introspecting and tweaking any behavior, whether it be plugin or built-in; smooth scrolling; TRAMP; emoji rendering that just works. Also if using Evil, you can be more vim than vim. In the : command entry in vim you can't use vim navigation, but there is a flag for that in Evil. Also in vim can't change the inclusivity of built in text-objects while you can in Evil.

> I think this is called referential transparency. This is not what I tried to describe. What I tried to describe is more on the interactive side of Emacs and elisp (but it also is possible to use that in a metaprograming style).

Just try both of them out? At least that’s how I got here.

I don't think comparing plugins (called packages in emacs) is really going to settle it. Vim (and Neovim) is a large enough ecosystem where any good ideas from the Emacs world (e.g. magit, org mode, etc.) have been ported over to Vim. There is a question of whether you want to use magit or org mode in vim, when it's not natively supported. But sizable portion of emacs users use evil, which is also non-native. Besides, I have found some features in Neovim that simply do not exist/are not as responsive in Emacs. 1) Telescope is amazing in Neovim. 2) Some things like fzf and evil mode are slow (my standards of latency are talking <50 milliseconds, as per [https://danluu.com/input-lag/](https://danluu.com/input-lag/), but your standards may vary). I have heard discussion on whether emacs is as fast as vim, but not the other way around, to give perspective. But what I think Vim nor Neovim doesn't have is interactivity. Not while using Vim I ever had to delve into its source code. I was working off of Vimscript, the abstraction layer provided by Vim (I presume it's the same in Neovim with Lua). In Emacs, it's (emacs) lisp all the way down. So the advantages of Emacs are similar to advantages of Lisp, in that they were designed to be interactive. When you want to change a setting in Neovim, I defaulted to changing my .vimrc and reloading it. In Emacs, you evaluate a function that changes the setting. There is incrementality?, interactivity, and liveness to it all. But if you are perfectly okay with edit-compile-run cycle, and see no point in live reloading or repl or direct feedback between you and your ideas, then Neovim is probably better. Neovim may be one of the best editors out there if you don't plan on changing a whole lot. But if you like tinkering, and want to experience and inspect and learn from open source software, I think Emacs is worth a try.

Can you render Latex or images inline? That's one critical feature that may be missing.

In these cases org modes babel extension. Is not available in vim. It's probably possible to do something similar though.