Things like this are why I use Emacs. Wonderful hack thanks for sharing.
Compare dead sibling’s recommendation[1] to the submission to understand what Emacs users mean when we talk about Emacs being easier to customize than the alternatives. VS Code is well and good for what it is, but it’s not a hacker’s editor.
And why I love doom emacs, it's almost like vscode in ease of getting set up for different languages. There's a init.el file with a :lang section where you can uncomment languages to enable them. Support for sh is enabled by default, and if shellcheck is installed it will use it without you having to customize anything. It's all the hackability of emacs when you want, but also just good defaults so everyone doesn't have to spend time configuring the same basic functionality.
I personally find that configuring vanilla emacs isn’t that scary. evil-mode + evil-collection provide most of the hard part of these distributions and I’ve found that growing from a minimal setup makes it easier to maintain your configuration than building on top of doom or spacemacs
Doom Emacs is minimal. You can configure it in pretty much the same way as vanilla Emacs without it getting in the way. I never felt my configuration was harder to maintain because of Doom. There are also modules you can enable that brings in a lot of packages, but they're purely optional. Personally, I find those modules to be sane and helpful.
Also, adding evil mode won't address half of my requirements for a baseline Emacs experience. There are performance optimizations in Doom that I wouldn't otherwise have known to put in my own configuration. I'm grateful there are people who are taking care of such details for users like me.
Normally, I avoid configuration frameworks. I don't use them in tmux, vim, or zsh. But Doom was the first configuration framework that I enjoyed using.
My configuration is 3k lines of lisp code (measured by cloc). Doom is about 44k. So, Doom's configuration is about 12 times large than mine and my configuration works for just about everything I need. Adding support for a new language is typically mostly figuring out how to get a language server and configuring eglot for it, then installing syntax-highlighting either via tree-sitter or with (use-package <language>-mode :ensure t). Addtitionally, just skimming doom's early-init.el[1], it makes a lot of questionable choices (like requiring the use of `doom sync` for stuff emacs just does by itself).
That LOC comparison doesn't make sense. It's 44k lines only if you enable every optional module, which no one ever does. On top of that, you're penalizing Doom for having better documentation by counting docstrings. Docstrings account for a large portion of Doom Emacs code.
Also, there are loads of people who need the things you found questionable or unnecessary. Including myself. I use modules for purposes other than adding support for new languages. But for language support, I sometimes need much more than just the first language server and syntax files that came up in a search result. The performance optimization you found questionable is an absolute must, too. Running "doom sync" to apply changes to configuration is a non-issue if that means faster startup.
I'd love doom emacs if it was an opinionated distro. Supporting competing alternatives for many packages means targeting a common denominator, and having a more buggy and fragile product than it has a right to be.
So the advantage of having someone else optimise a config is lost because most effort is spent supporting tons of optional packages. Meanwhile my hand written config is the definition of opinionated.
What's so hard about adding 5 lines to a config file? You're adding 100s of customizations that slow down emacs when you probably use a handful of them at most.
> You're adding 100s of customizations that slow down emacs
Doom Emacs' config loads faster than my hand-rolled one did.
So in that sense, with Doom I get a smaller config to maintain, for something that loads faster, while still having a rich/coherent set of features for the stuff I do bump into.
> Doom Emacs' config loads faster than my hand-rolled one did.
Having browsed the Doom config sources the other day, they put a lot of effort to minimize startup time; there are various trick there that tune Emacs itself to start faster, and can be copied over to one's own vanilla config :).
Sometimes packages don’t come with sane defaults. Or something conflicts somewhere. Im tempted to plunder doom config, but I suspect it’s not straight forward.
I still prefer it over flycheck personally cause from the compilation buffer you can quickly run through the errors and press "d" to add the disable meta comments to the source.
Flymake and flycheck have error list buffers, adding a disable meta comment to the source from it sounds like a really good idea, though. It would be cool if it was checker aware, ie. it would add a "noqa" comment for a flake8 error on a Python project.
I'm referring to using these tools with https://pre-commit.com. The wrappers work cross-platform and don't require folks interacting with the repo to install anything besides pre-commit itself and then running "pre-commit install" in the repo. The first time pre-commit is run, it then downloads and installs all of the hooks.
The wrappers also work well with CI systems if you want to enforce the pre-commit hooks in PRs.
Another advantage is that everyone interacting with the repo will be using the same versions of the tools.
If you're not using these tools with pre-commit, then sure, install them directly via your package manager of choice.
Oh cool, I wrote the package the author links to. I believe the person that implemented the version built into Emacs used code similar to mine, so both packages should behave more or less the same (it's not a lot of code, in any case).
Emacs has been used before most commenters on HN were born. They fail to understand or appreciate just how many hackers wrote custom editors with more or less an identical feature set as VS Code.
Sometimes I feel like we're just repeating computer history from the 80s onward.
Compare dead sibling’s recommendation[1] to the submission to understand what Emacs users mean when we talk about Emacs being easier to customize than the alternatives. VS Code is well and good for what it is, but it’s not a hacker’s editor.
[1] https://github.com/vscode-shellcheck/vscode-shellcheck