Takes a little while to acclimate, but it's very useful once you're used to it.
I've had a better experience tweaking the configuration in Lua as well. I never tried neovim's starter frameworks (NVChad, LunarVim, etc) so I can't compare them to emacs's. I was never able to use well emacs's frameworks because either they were too convoluted ann hard to customize or kept crashing.
Also when opening or formatting large files (sometimes not so large) emacs would freeze for a very long time. Also, LSP was not around, or was in its infancy, so my experience with code completion and intellisense was very poor, but perhaps that has changed.
Finally, emacs's plugin called "Magit" is a godsend and I lack a similar tool ever since.
With all that said emacs was very special for me because it fueled my passion for open software and being able to control and customize the tools I use. I really hope it got better and keeps kicking!
- The ecosystem is sometimes difficult. There is always a lot going on in terms of various completion frameworks and spellchecking. It is cool, but often you choice will have some consequences down the line. You like eglot, as a simple and faster alternative? Fine. But it does not support DAP, now you have to pull heavy LSP, treemacs and other 30 packages.
- Treesitter is a chance missed, they've introduced alternative mods for it, with a separate names, which makes it necessary to rewrite the hooks and generally makes a huge mess for no good reason. I guess, the reasoning was like "we do not want to force an external dependency", but there is simply no good reason to regex parsing if you have treesitter and it will be the standard, I am quite sure. Some kind of config switch for a mode would be a better solution.
- It is notably slower than neovim. I cannot describe it, it is more of a "micro-stutter here, micro-stutter there" feeling. It is more visible if you intend to use it for everything or as an IDE replacement, as an advanced editor emacs has a fine performance.
- The UI is... I don't know, I can never predict where a buffer will appear. Emacs in general will pop up a lot of buffers. Sometimes you can close them with q, sometimes you will have to hide them. "Inconsistent" is the word which comes into my mind.
- Org is outstanding as a technical outliner, so-so as a GTD tool. Sync problems and lack of good mobile clients shows.
- Configuring and introspection are good. I still have no idea how to debug my neovim config, for example, it is a non-issue in elisp, you don't even need to restart it, just eval parts of you elisp code!
- Embark is also a very very cool idea.
- Modern completion frameworks are good, vertico, marginalia, orderless - they are easy to configure and very performant. I just like Telescope in neovim more, since it looks better and shows a bigger code preview.
- Evil is a very good vim-like layer, but also quite heavy and sometimes you will have to deal with emacs keybindings. They are not bad, though, it makes sense to learn at least the basics. Due to evil I will leave the keybindings out in general, you can have it either way in emacs. Evil is the best vim implementation outside of vim/neovim.
I've settled on neovim with fish shell, git in console and occasionally lazygit and it is fine. It is hard to describe, but a focused, fast and composing editor is very pleasant to use. I also find neovim more aesthetically pleasant, although it is really just a personal perspective. But what is certainly is, is being simpler. Maybe it is just a natural consequence of aging, but I recognize a lot of value in simple tools: A lever espresso machine instead of a microcontroller-ridden monstrosity with a tablet attached, go instead of rust, console tooling instead of an IDE. Neovim just fits in.
In my workflow I embrace the chaos: commands/mode open windows as needed and I use winner-mode to restore my layout.
For example, if I have two side-by-side code windows open and I open magit with c-x g, it will create a new vertical split. Once I'm done with magit, I can use winner-undo once (or thrice depending on what magit ops I did) and it restores the original layout.
It was not the optimal solution, agreed. The reason was actually that a significant technical complexity was found while trying to adapt the existing modes. The syntax table vs. tree-sitter parse tree was simply too divergent for a mode to be just switched from one to the other. So the decision which I don't think anybody was completely happy with, but considered the only feasible way to move forward, to have new modes with tree-sitter.
You can see some discussion here: https://old.reddit.com/r/emacs/comments/15g9cna/why_is_emacs... and quick link to the mailing list thread: https://lists.gnu.org/archive/html/emacs-devel/2022-12/msg01...
I fixed that by redefining in my config split-window-preferred-function to my own function, which is responsible for the placement of new windows in a way that makes sense to me (which is something that no other piece of software does actually).