Consider not disabling menu-bar-mode by default

[cadadr]

Hi all!

As some of you might be aware, there's discussion regarding making Emacs more approachable to newcomers, over on emacs-devel. Distributions like Doom Emacs are part of the discussion, and it's a common conclusion that projects like yours are very helpful in this regard and there are ideas about collaboration and support.

As part of those discussions, trying to spot what some common patterns might be hiding some otherwise more discoverable functionality in Emacs, we came to the conclusion that the menu bar is important as a tool for discovering functionality, both a fixed set, and minor/major mode related stuff.

This is of course not a catch-all fix to the problems of the newcomers, and a lot of ideas are being produced around how to solve other, more major problems, but not disabling menu-bar-mode by default seems to be a step in the right direction.

So we thought that recommending distributions that seem to disable it by default to consider leaving that to the user instead. If you want to read more on the discussions, or contribute your views, please don't hesitate to do so on the emacs-devel mailing list.

[hlissner]

Hi! Sorry for being so late to the discussion. I'm on board with making Emacs more approachable to newcomers, but while I agree that the menu bar is a decent tool for discoverability, I don't think it's suited to Doom in particular.

Doom was designed to be keyboard-centric and targeted at experienced users, rather than beginners (though, admittedly, it attracts beginners in equal measure). I agree that discoverability is an issue, but I think there are better places to look for answers: perhaps M-x coupled with a completion framework, packages like which-key and helpful, or even something as simple as a functionality appendix in our documentation (to translate between feature and names of major/minor modes).

Really what repulses me most about the menu bar is that it introduces a new dimension of maintenance and repair work. Its defaults highlight commands, functionality, and workflows that Doom doesn't endorse, like the customize API (which introduces race conditions and load-order considerations that are a pain to accommodate along all our lazy-loading; I'd rather users simply configure it from their dotfiles) or package.el's API (Doom has its own package manager). Much work is needed to make the menu aware of Doom's augmentations or predilections.

Certainly, that can be fixed, and I'm open to PRs that add a module to "fix" the menu bar, but I don't think it's a good use of my time currently. I'm already stretched too thin as is. Perhaps I'll revisit the issue when I get around to writing a nano-emacs module way down the road -- an opportunity to reconsider Doom's UI decisions -- but at least until the menu bar has been tweaked (here, not upstream), I must refuse this change.

In any case, thanks for bringing it to my attention.