emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity

fix: disable UI elements earlier

Browse source 
Moves this from doom-ui to doom-start, since there is more savings to be
had if this is done early.

Also moves the menu-bar fix for macos out of the :os macos module into
doom-start, because it is a fix (and for a Doom optimization) and not a
feature, so it shouldn't be behind a module.
This commit is contained in:
Henrik Lissner 2022-09-15 19:02:26 +02:00
parent 1be11539e8
commit 41051f4761
No known key found for this signature in database
GPG key ID: B60957CA074D39A3
3 changed files with 28 additions and 29 deletions
Download patch file Download diff file Expand all files Collapse all files

16
lisp/doom-ui.el
View file

@ -255,22 +255,6 @@ windows, switch to `doom-fallback-buffer'. Otherwise, delegate to original
;; when resizing too many windows at once or rapidly.
(setq window-resize-pixelwise nil)
;; UI: Doom strives to be keyboard-centric, so I consider these UI elements
;; clutter. Initializing them also costs a morsel of startup time. Whats more,
;; the menu bar exposes functionality that Doom doesn't endorse. Perhaps one
;; day Doom will support these, but today is not that day.
;;
;; HACK: I intentionally avoid calling `menu-bar-mode', `tool-bar-mode', and
;; `scroll-bar-mode' because they do extra work to manipulate frame variables
;; that isn't necessary this early in the startup process.
(setq scroll-bar-mode nil
tool-bar-mode nil
;; Disabling `menu-bar-mode' causes focus issues on MacOS. The :os macos
;; module has a fix for this.
menu-bar-mode nil)
;; Setting `scroll-bar-mode' isn't enough to disable them, so:
(push '(vertical-scroll-bars) default-frame-alist)
;; UX: GUIs are inconsistent across systems, desktop environments, and themes,
;; and don't match the look of Emacs. They also impose inconsistent shortcut
;; key paradigms. I'd rather Emacs be responsible for prompting.