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

nit(cli): revise comments wrt site-run-file loading

Browse source
This commit is contained in:
Henrik Lissner 2024-09-01 13:03:31 -04:00
parent 2bc6dd2a96
commit 515f61295b
No known key found for this signature in database
GPG key ID: B60957CA074D39A3
3 changed files with 16 additions and 19 deletions
Download patch file Download diff file Expand all files Collapse all files

15
bin/doom
View file

@ -62,17 +62,14 @@
;; Put together, plus a strategically placed exit call, the shell will read
;; one part of this file and ignore the rest, while the elisp interpreter will
;; do the opposite.
;; - I intentionally avoid loading site files, so lisp/doom-cli.el can load them
;; by hand later. There, I can suppress and deal with unhelpful warnings (e.g.
;; "package cl is deprecated"), "Loading X...DONE" spam, and any other
;; disasterous side-effects.
;;
;; But be careful not to use -Q! It implies --no-site-lisp, which omits the
;; site-lisp directory from `load-path'.
;; - I intentionally suppress loading site files (must be done with '-q
;; --no-site-file' NOT '-Q', as the latter omits the site-lisp dir from
;; `load-path' too), so lisp/doom-cli.el can load them manually later (early
;; in lisp/doom-cli.el). Look there for an explanation why I do this.
;; - POSIX-compliancy is paramount: there's no guarantee what /bin/sh will be
;; symlinked to in the esoteric OSes/distros Emacs users use.
;; - The user may have a noexec flag set on /tmp, so pass the exit script to
;; /bin/sh rather than executing them directly.
;; - The user may have mounted /tmp with a noexec flag, so pass the exit script
;; to /bin/sh rather than executing them directly.
;; In CLI sessions, prefer correctness over performance.
(setq load-prefer-newer t)

12
lisp/doom-cli.el
View file

@ -23,12 +23,12 @@
doom-cache-dir
doom-state-dir))
;; HACK: bin/doom invokes Emacs with --no-site-lisp so that site files can be
;; loaded manually, here, where I can suppress any output it produces, and
;; they almost always produce some. This output pollutes the output of doom
;; scripts with potentially confusing -- but always unimportant --
;; information to the user, like deprecation notices, file-loaded messages,
;; and linter warnings. With this, that output is suppressed.
;; HACK: bin/doom suppresses loading of site files so they can be loaded
;; manually, here. Why? To suppress the otherwise unavoidable output they
;; commonly produce (like deprecation notices, file-loaded messages, and
;; linter warnings). This output pollutes the output of doom's CLI (or
;; scripts derived from it) with potentially confusing or alarming -- but
;; always unimportant -- information to the user.
(quiet!
(require 'cl nil t) ; "Package cl is deprecated"
(unless site-run-file ; unset in doom.el

8
lisp/doom.el
View file

@ -502,10 +502,10 @@ users).")
;; PERF,UX: site-lisp files are often obnoxiously noisy (emitting output
;; that isn't useful to end-users, like load messages, deprecation
;; notices, and linter warnings. Displaying these in the minibuffer causes
;; unnecessary redraws at startup which can impact startup time
;; drastically and cause flashes of white. It also pollutes the logs. By
;; suppressing it here, I load it myself, later, in a more controlled way
;; notices, and linter warnings). Displaying these in the minibuffer
;; causes unnecessary redraws at startup which can impact startup time
;; drastically and cause flashes of white. It also pollutes the logs. I
;; suppress it here and load it myself, later, in a more controlled way
;; (see `startup--load-user-init-file@undo-hacks').
(put 'site-run-file 'initial-value site-run-file)
(setq site-run-file nil)