emenel/doomemacs
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity
doomemacs/modules/config/literate/init.el

50 lines
1.9 KiB
EmacsLisp
Raw Normal View History

config/literate: earlier check & no byte-compile Making the compile check happen earlier fixes an edge case where the resulting files from a literate config being tangled into multiple files aren't recognized by Doom's package management or autoload generation systems. Disabling byte-compiling fixes an all too common issue where packages and macros are undefined at compile time, causing a plethora of invalid function errors. Leave byte-compilation to `bin/doom compile`!
2018-06-08 16:23:13 +02:00
;;; config/literate/init.el -*- lexical-binding: t; -*-
compile/literate: refactor & recompile on save And add autoloaded commands. This may need work to ensure you don't spawn multiple instances of Emacs all vying to compile the same file.
2018-06-05 16:09:03 +02:00
(defvar +literate-config-file
(expand-file-name "config.org" doom-private-dir)
"The file path of your literate config file.")
Add :config literate module It will tangle and byte-compile a config.org in your private config. Doom will then load the resulting config.elc later. Org is only loaded when updating this file.
2018-06-05 15:38:58 +02:00
Refactor config/literate module + Now recompiles literate config if you modify org files in DOOMDIR + Replaced +literate/compile with +literate/reload + Calls org-babel-tangle-file directly if org package is loaded + Change mtime check mechanism for literate tangling at startup
2019-03-28 01:59:25 -04:00
(defvar +literate-config-cache-file
(expand-file-name "literate-last-compile" doom-cache-dir)
compile/literate: refactor & recompile on save And add autoloaded commands. This may need work to ensure you don't spawn multiple instances of Emacs all vying to compile the same file.
2018-06-05 16:09:03 +02:00
"The file path that `+literate-config-file' will be tangled to, then
byte-compiled from.")
Add :config literate module It will tangle and byte-compile a config.org in your private config. Doom will then load the resulting config.elc later. Org is only loaded when updating this file.
2018-06-05 15:38:58 +02:00
;;
Refactor config/literate module + Now recompiles literate config if you modify org files in DOOMDIR + Replaced +literate/compile with +literate/reload + Calls org-babel-tangle-file directly if org package is loaded + Change mtime check mechanism for literate tangling at startup
2019-03-28 01:59:25 -04:00
(defun +literate-tangle (&optional force-p)
"Tangles `+literate-config-file' if it has changed."
(let ((default-directory doom-private-dir)
(org +literate-config-file))
(when (or force-p (file-newer-than-file-p org +literate-config-cache-file))
config/literate: log compilation
2018-06-05 16:14:38 +02:00
(message "Compiling your literate config...")
config/literate: earlier check & no byte-compile Making the compile check happen earlier fixes an edge case where the resulting files from a literate config being tangled into multiple files aren't recognized by Doom's package management or autoload generation systems. Disabling byte-compiling fixes an all too common issue where packages and macros are undefined at compile time, causing a plethora of invalid function errors. Leave byte-compilation to `bin/doom compile`!
2018-06-08 16:23:13 +02:00
config/literate: set config.el as default target
2019-03-29 03:40:56 -04:00
(let* ((org (file-truename +literate-config-file))
(dest (concat (file-name-sans-extension org) ".el")))
(or (and (if (fboundp 'org-babel-tangle-file)
(org-babel-tangle-file org dest "emacs-lisp")
;; We tangle in a separate, blank process because loading it
;; here would load all of :lang org (very expensive!).
(zerop (call-process
"emacs" nil nil nil
"-q" "--batch" "-l" "ob-tangle" "--eval"
(format "(org-babel-tangle-file %S %S \"emacs-lisp\")"
org dest))))
;; Write the cache file to serve as our mtime cache
(with-temp-file +literate-config-cache-file
(message "Done!")))
(warn "There was a problem tangling your literate config!"))))))
config/literate: earlier check & no byte-compile Making the compile check happen earlier fixes an edge case where the resulting files from a literate config being tangled into multiple files aren't recognized by Doom's package management or autoload generation systems. Disabling byte-compiling fixes an all too common issue where packages and macros are undefined at compile time, causing a plethora of invalid function errors. Leave byte-compilation to `bin/doom compile`!
2018-06-08 16:23:13 +02:00
Add :config literate module It will tangle and byte-compile a config.org in your private config. Doom will then load the resulting config.elc later. Org is only loaded when updating this file.
2018-06-05 15:38:58 +02:00
compile/literate: refactor & recompile on save And add autoloaded commands. This may need work to ensure you don't spawn multiple instances of Emacs all vying to compile the same file.
2018-06-05 16:09:03 +02:00
;; Let 'er rip!
Half-revert 92e604d0 + Fixes config.org buffer being killed when tangled + Tangle files in same session if ob-tangle is loaded (and in noninteractive sessions). i.e. only tangle quietly when starting up interactive Emacs.
2019-03-28 15:07:39 -04:00
(when noninteractive
(require 'ob-tangle nil t))
(+literate-tangle (or doom-reloading-p noninteractive))
Add :config literate module It will tangle and byte-compile a config.org in your private config. Doom will then load the resulting config.elc later. Org is only loaded when updating this file.
2018-06-05 15:38:58 +02:00
;; No need to load the resulting file. Doom will do this for us after all
;; modules have finished loading.
Refactor config/literate module + Now recompiles literate config if you modify org files in DOOMDIR + Replaced +literate/compile with +literate/reload + Calls org-babel-tangle-file directly if org package is loaded + Change mtime check mechanism for literate tangling at startup
2019-03-28 01:59:25 -04:00
;; Recompile our literate config if we modify it
(after! org
:boom: revise hook/var fns naming convention (2/2) This is second of three big naming convention changes. In this commit, we change the naming conventions for hook functions and variable functions: 1. Replace the bar | to indicate a hook function with a -h suffix, e.g. doom|init-ui -> doom-init-ui-h doom|run-local-var-hooks -> doom-run-local-var-hooks-h 2. And add a -fn suffix for functions meant to be set on variables, e.g. (setq magit-display-buffer-function #'+magit-display-buffer-fn) See ccf327f8 for the reasoning behind these changes.
2019-07-18 15:27:20 +02:00
(add-hook 'after-save-hook #'+literate-recompile-maybe-h))
Reference in a new issue Copy permalink