doomemacs/modules/input/layout/config.el

;;; input/layout/config.el -*- lexical-binding: t; -*-

(add-hook! 'doom-after-modules-config-hook
  (defun +layout-init-h ()
    (cond ((modulep! +bepo)
           (load! "+bepo"))
          ((modulep! +azerty)
           (load! "+azerty")))))
input/layout: major refactor To conform the module to Doom's naming and style conventions. This introduces two breaking changes: + doom-bepo-cr-rotation-style was renamed +layout-bepo-cr-rotation-style + Replaces the doom-bepo- prefix for this module's bepo library with +layout-bepo- And the following fixes: + Corrects the file path in file header comments. + input/layout/autoload/bepo.el is no longer compiled/indexed if +bepo isn't activated. 2021-05-01 00:56:08 -04:00			`;;; input/layout/config.el -- lexical-binding: t; --`
Add support for bépo layout in a dedicated module Evil is loaded too early to be able to wait for the config.el file of a user to set the CR-rotation style variable. 2020-08-14 21:41:25 +02:00
refactor!: redesign module init/config hooks BREAKING CHANGE: For consistency and correctness, I've renamed the module init/config hooks, and added new ones: - Adds doom-before-modules-config-hook - Adds doom-after-modules-config-hook (replaced doom-before-init-modules-hook) - Adds doom-before-modules-init-hook - Adds doom-after-modules-init-hook (replaced doom-init-modules-hook) - Removed doom-after-init-modules-hook (replaced w/ after-init-hook) The old naming (and timing) was counterintuitive. Now, it's named after the loaded file group (init.el vs config.el), and I added before/after variants. Altogether, this should make them less ambiguous. I've also moved some functions in various modules to more correct hooks. Load order before this change: - $EMACSDIR/early-init.el - $EMACSDIR/lisp/doom.el - $EMACSDIR/lisp/doom-start.el - $DOOMDIR/init.el - {$DOOMDIR,~/.emacs.d}/modules///init.el - `doom-before-init-modules-hook' - {$DOOMDIR,~/.emacs.d}/modules///config.el - `doom-init-modules-hook' - $DOOMDIR/config.el - `doom-after-init-modules-hook' - `after-init-hook' - `emacs-startup-hook' - `window-setup-hook' Load order after this change: - $EMACSDIR/early-init.el - $EMACSDIR/lisp/doom.el - $EMACSDIR/lisp/doom-start.el - $DOOMDIR/init.el - `doom-before-modules-init-hook' - {$DOOMDIR,~/.emacs.d}/modules///init.el - `doom-after-modules-init-hook' - `doom-before-modules-config-hook' - {$DOOMDIR,~/.emacs.d}/modules///config.el - `doom-after-modules-config-hook' - $DOOMDIR/config.el - `after-init-hook' - `emacs-startup-hook' - `window-setup-hook' 2022-09-14 14:48:21 +02:00			`(add-hook! 'doom-after-modules-config-hook`
input/layout: major refactor To conform the module to Doom's naming and style conventions. This introduces two breaking changes: + doom-bepo-cr-rotation-style was renamed +layout-bepo-cr-rotation-style + Replaces the doom-bepo- prefix for this module's bepo library with +layout-bepo- And the following fixes: + Corrects the file path in file header comments. + input/layout/autoload/bepo.el is no longer compiled/indexed if +bepo isn't activated. 2021-05-01 00:56:08 -04:00			`(defun +layout-init-h ()`
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition. 2022-08-12 20:29:19 +02:00			`(cond ((modulep! +bepo)`
input/layout: initial azerty commit 2021-05-01 08:20:34 +02:00			`(load! "+bepo"))`
refactor: deprecate featurep! for modulep! featurep! will be renamed modulep! in the future, so it's been deprecated. They have identical interfaces, and can be replaced without issue. featurep! was never quite the right name for this macro. It implied that it had some connection to featurep, which it doesn't (only that it was similar in purpose; still, Doom modules are not features). To undo such implications and be consistent with its namespace (and since we're heading into a storm of breaking changes with the v3 release anyway), now was the best opportunity to begin the transition. 2022-08-12 20:29:19 +02:00			`((modulep! +azerty)`
input/layout: initial azerty commit 2021-05-01 08:20:34 +02:00			`(load! "+azerty")))))`