Editor frameworks are not frameworks

2 points by caligian 3 days ago

I have always felt that doom-emacs and doom-nvim are imcomplete frameworks. Both of them have an obsession with lazy-loading and deferring packages which always goes wrong. I got horribly annoyed with nvim-surround's inability to set the keybindings after directly opening a file rather than just nvim and doom emacs kept breaking after small workflow changes. As an experiment, I tried vanilla-evil configured emacs with lots of my own libraries and it pretty much opened in the same time as doom-emacs.

Secondly, doom does not provide anything for encouraging users to create their own APIs apart from some macros for configuring the framework. It does not have a proper stateful storage mechanism like being able to change use-package forms, add more mappings or configure a language properly apart from it's fancy API used to enable/disable packages, pins packages for no good reason and I don't like the way code has been organized wrt all the reinvented functions for dealing with mappings and other stuff. For instance, the author has a macro wrapper over general-define-key for no good reason . It makes more sense to have a cond-like DSL where the state name is the cond-case for making multiple general-define-key mappings. The author fails to include a REPL or a anywhere-shell library and something that automates compile based on workspace or patterns-matching using 'make-process' - really good API that matches plenary.nvim without bells and whistles all of which is present in doom-nvim.

As a result I have long abandoned using frameworks rewritting my own with stateful configurations where each object is tagged by name and a powerful set of custom primitives like terminal, compiler, formatter objects with a lua-like table structure powered by ht and eieio. Now the stupid problem of keymaps and hooks not loading and byte-compilation crap, my configuration feels much more productive than doom