How do the neovim plugins for OrgMode and Magit compare with the real thing?

[deleted]

Org's feature set absolutely dwarfs neorgs. The documentation for neorg outlines its capabilities pretty well. I would assume neorg performance is better, but org's performance is just fine in my experience. Is anything keeping you from trying out one tool or the other to see which fits your specific use cases better?

I'll be completely honest: I've always been just a light VSC user because my coding has been very light, mostly for some work stuff. But I'm now working on a personal project that is likely going to take years to develop and involve a lot of coding, so I am looking to jump in all the way into a more hardcore dev environment and currently debating between learning emacs and [helix](https://helix-editor.com/). Helix btw, not neovim, because I'm more interested in working with kakoune key bindings than vim bindings. If emacs had a layer for kakoune as comprehensive as evil, I think it would be a no-brainer, but such as it is, [kakoune.el](https://github.com/jmorag/kakoune.el) is the closest we have which isn't quite was I was hoping for. This question stems from me trying to weigh the pros and cons of using helix for the native keybindings I want vs how inferior (or not?) the plugins that might be developed for it emulating emacs' killers apps might be. So >Is anything keeping you from trying out one tool or the other to see which fits your specific use cases better? Only the learning curve of learning both emacs and neovim just to test out these apps, which is why I'm asking this here. So when you say >Org's feature set absolutely dwarfs neorgs. If I understand you correctly, you mean emacs' org-mode feature set dwarfs the neovim plugins? If so, can you tell me if that's only because these plugins haven't been worked on nearly as extensively as the org-mode layer for emacs? Or is there something fundamental about the neovim model which decouples the editor from the plugin system that makes it impossible to implement those features, or implement them nearly as elegantly?

For the last thing, you should keep in mind that nvim is TUI, while emacs is GUI.

No emacs is not a GUI Programm it is a TUI Programm in a GUI

Emacs is a GUI program, you have buttons, menus, icons, prop text, images

Org-mode has so many more features. You can compare them only if the subset offered by NeoOrg is enough for you. NeoOrg does not offer: - Inline images - Code Blocks - Literate programming - Spreadsheet capabilities - Latex fragments inline preview - Exporting org mode to various formats Among these the Code Blocks is huge. Code blocks allow you to do anything you can do in Jupyter Notebooks. For my personal use case NeoOrg is way too limited because I use all of the features above. I personally do not care about performance. Emacs can be slow and the single thread is a pain in the butt sometimes. Even so Emacs is so much worth it. I cannot comment on NeoGit but I do use Magit every day and it has changed completely how I work on my projects. My only regret is not learning more about Emacs years ago.

Exactly! You can also use it as TUI program but the GUI has so much more to offer.

You can write orgdown files in vim, but you won't find org-mode outside of Emacs. Just go with the clear winner here if you want all that org has to offer. I've tried all the vim-orgs in my last recent foray into Neovim. It was at best busy work and at worst, kind of a waste of time.

Have you seen meow modal mode? https://github.com/meow-edit/meow

It has exactly the same functionality in a terminal, the only difference is how you access it. Which is also the same for the many users who turn off the menu and toolbar.

You should probably cross-post this question over to neovim sub. Emacs has the canonical implementations, while clones in neovim are catching up. People who use the Emacs version will have absolutely no need to check out and keep up with progress of clones when they have the real thing. The brilliance of Magit over git is mostly in UI and workflow. Once Magit nailed that, it's should theoretically be easy enough to port. However, both Magit and Org-mode demonstrates a gestalt effect because of a cohesive vision, that superficial feature clones or platform difference will always likely fail to capture. Anyway, my 30 minute impressions is that feature wise NeoGit seems on right track, but quite a few essential features are still missing. I can see that it's doing basic things like pull, push, commit. It's good that region/hunk based add, discard exists because that's essential. But heck, it doesn't even have fetching and merging yet, much less complicated conflict resolution. It also doesn't have basic things like reset, revert, reflog, cherrypick, bisect, diff between branches, tagging, remote and submodule management, patch handling and so on. So when it comes to neogit, in summary: - Magit is a much more thorough and complete system. Not only in terms of git, but these days Magit supports all major forges, so basically you can interact with Github/Gitlab and handle things like PR, discussions, issues and so on, which neogit is *years* away from doing since they have glaring feature omissions in just git compatibility. - Magit and org-mode have cohesive visions of their own that grew organically from the strength of its platform that it leverages. Things like Emacs' uniform completion system and minor modes transparently shadowing keybinds (ironically, "modal" vim can't do that) means spirit of Magit felt quite lost in neogit. Also, Emacs already has *multiple* high quality conflict management tooling like Ediff or Smerge. I don't think vimdiff quite compares to Ediff, but it's still very good, except the NIH syndrome in NeoVim means it simply won't use that and instead have a glaring hole in feature until this is implemented in neogit someday. ----- If I wanted to enumerate all features of Org-mode that doesn't exist in NeoOrg, I will be here all day. Sorry but NeoOrg is basically all front-end. It's doing things like syntax highlighting, folding, source block highlight and such fine. But that makes it a markdown alternative, which is lightyears away from what orgmode in Emacs is about. They put this in their readme: > We need our own, better solution Which is impossible to read in any way other than: org-mode is too vast in scope and impossible to clone in full, so we will pick features that we like and maybe add something of our own. Which, frankly, is fine. They may find that the limited feature set is all they need or can reasonably implement, so it will be logical for them to prioritise. But that's a different point from the question you asked.

Org has been worked on a lot longer which is at least part of it. I'm not sure if neorg could ever support the feature set that org does. Take, for example, neorg's export implementation. Best case scenario, neorg integrates with pandoc and exports that way. Pandoc isn't perfect, and doesn't offer the same customization as Emacs. In emacs, you can create your own backend and integrate it seamlessly with org-export. You can even derive your own backend from another backed on your system. You can apply post-processing filters, which neorg might offer eventually but they still won't be as easy to tune. If you don't need to export stuff, though, it's a moot point. I suggest making a list of what you want to be able to do, and if neorg works, use it. If making a list seems daunting, or you suspect it will change as time goes on, I would use Emacs. Also another poster mentioned meow mode. Definitely give that a shot. I use it and love it. You might be able to get the kakoune experience you're looking for. Also if you get stuck, the community has been a huge help when I got started.

To you and /u/kamui78 \- appreciate the great answers! >You should probably cross-post this question over to neovim sub. [Yep](https://www.reddit.com/r/neovim/comments/wi4s8w/how_do_the_neovim_plugins_for_orgmode_and_magit/) :) Damn it, so frustrating. Like I said, if emacs had a layer for kakoune/helix bindings as complete and maintained as Evil, *there would be no question*. I would be on emacs like white on rice. Even though I'm not the biggest fan of dynamic languages like elisp, I very much prefer emacs' approach to neovim's et al decoupling of editor or base platform from plugin layer. Honestly, my fantasy IDE would be something *very* much like emacs, but ported from the ground up in rust and streamlined a bit to avoid some of the bloat, and using [RustPython](https://github.com/RustPython/RustPython) or similar for scripting the layers, including a *badass* kakoune/helix emulator. I know some [projects along these lines](https://github.com/emacs-ng/emacs-ng) are being attempted but they look to be years away from appreciable maturity, if ever.

>In emacs, you can create your own backend and integrate it seamlessly with org-export. Ahhh ok, very interesting usecase! This is *exactly* the kind of stuff I was looking for, thank you. So I do see that from the [features](https://orgmode.org/features.html) >**Developers can easily create new backends for their favorite format** (see the ox reference documentation) and Org is also supported by Pandoc. whereas you're saying the neovim user would be locked into whatever integration the neoorg author implemented in the plugin? Ok makes sense but let me ask you this: See, I'm just really curious about the difference in this "more tightly integrated platform2elisp" model that emacs has, vs the "more decoupled platform2plugins" model that neovim et al have, and if there truly are limitations to the latter. Now you said a couple of key phrases here * "I'm not sure if neorg could **ever** support the feature set that org does." * "**Best case scenario**, neorg integrates with pandoc and exports that way." Can you clarify why that's the best case scenario? Is there really a technological limitation to the neoorg author from including additional functionality within the plugin allowing the user to specify their own backend as well?

> are being attempted but they look to be years away from appreciable maturity, if ever. Yeah most likely they won't mature at all. Many of the emacs-ng folks were doing an incremental Rust rewrite called [Remacs](https://github.com/remacs/remacs) before abandoning that. It's great to see these people having fun, but I wouldn't bet on them to be around in the long term. And that also applies to solo projects like NeoGit and NeoOrg tbh. When I said they are years away from feature parity, that's being charitable. In a few years, most likely they will be abandoned. Both emacs-devel and org-devel are pretty vibrant mailing lists, which speaks volume for their long term health, even after all this time. Magit almost feels like a professionally developed tool because of its polish and careful consideration to even corner UI cases. I forgot to mention that I was doing an interactive rebase in neogit and it bailed at first conflict, and now there is no option to abort so I need CLI to get unstuck. End of the day such things are understandable, but just goes on to show it's no Magit. > Even though I'm not the biggest fan of dynamic languages like elisp Well I also hate dynamic languages as much as the next guy, but I think this is unavoidable if you want to script a living breathing live system. I also don't think traditional software development cautions are not of much use here, because we are talking about a giant ball of global and mutable state which goes against every sensible practice, and pretty much every bit of code you will write will *intentionally* have side-effect. End of the day it's not bad, elisp is fun and that's important :) > if emacs had a layer for kakoune/helix bindings as complete and maintained as Evil, there would be no question One thing you could do is treat Magit and Org-mode as distinct applications, you might still get value out of it. In org-mode you will mostly be writing prose, documentation, agenda etc. and imo modal editing is fairly useless/unnecessary overhead in those scenarios. I probably code more in neovim than Emacs on any given day (for reasons that aren't really a black mark on Emacs, unless you consider me being addicted to master branch is Emacs' fault which makes it hard to deploy it in remote machines where I often have to work). But I still use Emacs everyday for things like Email, personal knowledge management, journaling and note taking, bookmark system, ebook reading and so on. Personally I prefer Emacs to Vim styled modal editing for everything (with heavy personalisation of course, which is the Emacs way) - maybe I am closer to neutrality when it comes to coding, but I don't really see the point of modal editing outside of that scenario. P.S. If the difference between expectation and reality isn't too much, maybe you can contact the kakoune.el author with your feedback. Or maybe you can hack on it yourself :D

>It has exactly the same functionality in a terminal How can you get propertized text or images in a terminal? (you can't)

I mean, that's not *entirely* true, right? You can get images, though whether you can or not is restricted by which terminal you use. And I'm sure not all properties work but I can get bold, italics, underline, and color font properties easily in my terminal. You can even get mouse functionality with `xterm-mouse-mode` and `mouse-wheel-mode` set to `t`. But you're certainly not incorrect that you're still limited, in certain ways, when you move to the terminal. And, if we take TUI to mean in a TTY context, this becomes deterministically so.

>You can get images, though whether you can or not is restricted by which terminal you use. Some terminals (like kitty I believe) may have non-standard ways to display images, and there are some other even less standard ways to display images (like ueberzug), but I'm quite sure none of those are supported by emacs. >And I'm sure not all properties work but I can get bold, italics, and font properties easily in my terminal. Yes, italics, bold and colors are pretty standard, that's what terminals were designed for. But there is no way to resize, shift up/down, mix font families (like icons from all-the-icons), or mix font types, most notably of those, use variable width fonts in terminal. I don't have to tell what an amazing feature that last one alone is for people who write larger texts in org mode. And then there's other features that benefit a more modern UI, like single pixel window separators instead of a full character wide line or scroll bars of various kinds, and context-menus that don't work in the terminal. Don't get me wrong, terminal emacs and that it works as well as it does is a remarkable feat of software-engineering, but the GUI version is much, much preferable.

As a caveat to my response, I have spent countless hours in Emacs, my Neovim/Neorg experience pales in comparison. It's also worth pointing out that I started on Emacs and Neovim at the same time. I actually wanted to like Neovim more because it's newer, more efficient, etc. In spite of all of that, I stuck with Emacs because tinkering is enjoyable. I don't find tinkering with Neovim fun at all. Finally, to answer your questions: You're not necessarily locked into a backend with Neorg, you could create your own backend, but the process looks more difficult and time-consuming than org. I have not invested the time in Neorg to say if this is generally true or if it depends on the backend you want to set up. I nitpick a lot in general, and Emacs gives you the ability to make things the way you want it. You won't be able to use that ability until after you tinker with it for some time, but you can often find code snippets online until you can write your own code. This mutability is the primary reason I prefer the "platform2elisp" model as you put it. The source code is almost a template, functions can be redefined ad-hoc to suit your needs. Neovim and Neorg can't offer that, and I would consider that a limitation. I was probably a little reductive with my best case scenario statement. The Neorg dev stated in a random issue thread last year that the dream was to have an engine for pandoc. Other engines will and do exist (e.g. markdown), but the documentation is lacking for now in my opinion, and I personally have had a difficult time figuring out how to tweak things. This will get better in time, but it's hard to say how long. Separately, the configuration APIs for Neovim plugins feel more restrictive than in Emacs. This may not be empirically true, but going back to exporting as an example. I've been able to get output exactly how I want in Emacs, but there were several things I couldn't figure out how to do in Neorg. Lastly, since I don't think I emphasized it much, the customization you get with Emacs comes from learning Elisp, I'm afraid. It's not a bad language, I think it's a fun change of pace from C#, Rust, Python, etc. But lisps are their own thing if you haven't worked with them, and I would say the amount of time it takes to get to your ideal state is directly proportional to how well you understand (not necessarily write) elisp. The same is true for Neovim and Lua (Neovim can be configured with multiple languages, btw), but Lua at least feels similar to other languages you see often these days, and it seems like a pretty versatile language that's quite valuable outside of Neovim.