refactor: minor refactors & commentary revision

* lisp/doom-cli.el:
  - reference backport source commit.
  - doom-cli--restart: a type check is all we need here. This is a
    programmer error, not a user error.
* lisp/doom-editor.el (recentf): mention recentf-show-abbreviated (added in
  emacs-mirror/emacs@32906819ad)
* lisp/doom-keybinds.el (doom-init-leader-keys-h): move to
  doom-after-init-hook, in case the user customizes leader variables in
  a previous hook (like emacs-startup-hook or after-init-hook).
* lisp/doom-start.el: use eval-when! to compile out the section on
  non-macOS systems (when Doom gets around to compiling its core files,
  later).
* modules/config/literate/autoload.el (+literate-config-file): use
  file-name-concat instead of string concat. This relaxes the
  requirement that doom-user-dir end in a /; a requirement I intend to
  fully phase out.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-non-package): remove
  empty map! macro in flycheck-emacs-lisp-check-form. The macro already
  no-ops at compile-time/in noninteractive sessions since b480ed51a3.
* modules/ui/hl-todo/config.el (hl-todo-keyword-faces): revise
  commentary for default hl-todo keywords.

Ref: emacs-mirror/emacs@32906819ad
Ref: b480ed51a3
This commit is contained in:
Henrik Lissner 2022-09-24 11:01:49 +02:00
parent f0431b6fac
commit 1c4217aa27
No known key found for this signature in database
GPG key ID: B60957CA074D39A3
9 changed files with 42 additions and 34 deletions

View file

@ -6,21 +6,23 @@
:config
(setq hl-todo-highlight-punctuation ":"
hl-todo-keyword-faces
'(;; For missing features or functionality that should be added at a
;; later date.
'(;; For reminders to change or add something at a later date.
("TODO" warning bold)
;; For code (or code paths) that are broken or slow, and may become
;; bigger problems later.
;; For code (or code paths) that are broken, unimplemented, or slow,
;; and may become bigger problems later.
("FIXME" error bold)
;; For code smells, where questionable coding practices are
;; intentionally used, and/or may break in a future update.
("HACK" font-lock-constant-face bold)
;; For things that need confirmation that they work or more testing.
;; For code that needs to be revisited later, either to upstream it,
;; improve it, or address non-critical issues.
("REVIEW" font-lock-keyword-face bold)
;; For things that just gotta go and will soon be gone.
;; For code smells where questionable practices are used
;; intentionally, and/or is likely to break in a future update.
("HACK" font-lock-constant-face bold)
;; For sections of code that just gotta go, and will be gone soon.
;; Specifically, this means the code is deprecated, not necessarily
;; the feature it enables.
("DEPRECATED" font-lock-doc-face bold)
;; These are extra, commonly seen annotation keywords. What they mean
;; or are for depend on the project.
;; Extra keywords commonly found in the wild, whose meaning may vary
;; from project to project.
("NOTE" success bold)
("BUG" error bold)
("XXX" font-lock-constant-face bold)))