2017-02-11 13:46:42 +08:00
|
|
|
;; -*- no-byte-compile: t; -*-
|
|
|
|
|
;;; core/packages.el
|
|
|
|
|
|
:boom: Replace exec-path-from-shell w/ 'bin/doom env'
IMPORTANT: This is a breaking update for Mac users, as your shell
environment will no longer be inherited correctly (with the removal of
exec-path-from-shell). The quick fix is: 'bin/doom env refresh'. Also,
the set-env! autodef now does nothing (and is deprecated), be sure to
remove calls to it in your config.
Smaller changes:
+ This update also adds --no-* switches to doom quickstart
+ Includes general improvements to the documentation of several bin/doom
commands.
+ Moves doom/reload* commands to core/autoload/config.el
+ doom/reload-project has been removed (it didn't actually do anything)
The breaking change:
This update adds an "envvar file" to Doom Emacs. This file is generated
by `doom env refresh`, populated with variables scraped from your shell
environment (from both non-interactive and interactive sessions). This
file is then (inexpensively) loaded at startup, if it exists.
+ The file is manually generated with `doom env refresh`.
+ It can be regenerated automatically whenever `doom refresh` is run by
running `doom env enable` (`doom env clear` will reverse this and
delete the env file).
+ `doom quickstart` will ask if you want to auto-generate this envvar
file. You won't need it if you're confident Emacs will always be
started from the correct environment, however.
+ Your env file can be reloaded from a running Emacs session with `M-x
doom/reload-env`. Note: this won't work if the Emacs session you're
running it in doesn't have a correct SHELL set. i.e. don't use this to
create your first env file!
The idea isn't mine -- it's borrowed from Spacemacs -- and was
introduced to me in #1053 by @yurimx. I was impressed with it. Prior to
this, I was unhappy with exec-path-from-shell (no hate to the dev, I
understand its necessity), and 'doom patch-macos' wasn't ideal for mac
users (needed to be reapplied every time you update Emacs). What's more,
many users (even Linux users) had to install exec-path-from-shell
anyway.
This solution suffers from none of their shortcomings. More reliable
than patch-macos, more performant and complete than
exec-path-from-shell, and easily handled by bin/doom.
2019-03-28 12:06:10 +08:00
|
|
|
;; core.el
|
2019-07-21 20:49:09 +08:00
|
|
|
(package! auto-minor-mode)
|
2019-12-27 14:52:45 +08:00
|
|
|
(package! async)
|
2019-12-20 11:07:06 +08:00
|
|
|
(package! gcmh)
|
:boom: Replace exec-path-from-shell w/ 'bin/doom env'
IMPORTANT: This is a breaking update for Mac users, as your shell
environment will no longer be inherited correctly (with the removal of
exec-path-from-shell). The quick fix is: 'bin/doom env refresh'. Also,
the set-env! autodef now does nothing (and is deprecated), be sure to
remove calls to it in your config.
Smaller changes:
+ This update also adds --no-* switches to doom quickstart
+ Includes general improvements to the documentation of several bin/doom
commands.
+ Moves doom/reload* commands to core/autoload/config.el
+ doom/reload-project has been removed (it didn't actually do anything)
The breaking change:
This update adds an "envvar file" to Doom Emacs. This file is generated
by `doom env refresh`, populated with variables scraped from your shell
environment (from both non-interactive and interactive sessions). This
file is then (inexpensively) loaded at startup, if it exists.
+ The file is manually generated with `doom env refresh`.
+ It can be regenerated automatically whenever `doom refresh` is run by
running `doom env enable` (`doom env clear` will reverse this and
delete the env file).
+ `doom quickstart` will ask if you want to auto-generate this envvar
file. You won't need it if you're confident Emacs will always be
started from the correct environment, however.
+ Your env file can be reloaded from a running Emacs session with `M-x
doom/reload-env`. Note: this won't work if the Emacs session you're
running it in doesn't have a correct SHELL set. i.e. don't use this to
create your first env file!
The idea isn't mine -- it's borrowed from Spacemacs -- and was
introduced to me in #1053 by @yurimx. I was impressed with it. Prior to
this, I was unhappy with exec-path-from-shell (no hate to the dev, I
understand its necessity), and 'doom patch-macos' wasn't ideal for mac
users (needed to be reapplied every time you update Emacs). What's more,
many users (even Linux users) had to install exec-path-from-shell
anyway.
This solution suffers from none of their shortcomings. More reliable
than patch-macos, more performant and complete than
exec-path-from-shell, and easily handled by bin/doom.
2019-03-28 12:06:10 +08:00
|
|
|
|
2017-02-11 13:46:42 +08:00
|
|
|
;; core-ui.el
|
2019-02-18 03:44:23 +08:00
|
|
|
(package! all-the-icons)
|
2018-03-03 06:40:51 +08:00
|
|
|
(package! hide-mode-line)
|
2017-02-23 13:06:12 +08:00
|
|
|
(package! highlight-numbers)
|
|
|
|
|
(package! rainbow-delimiters)
|
2018-05-14 05:16:06 +08:00
|
|
|
(package! restart-emacs)
|
2017-02-11 13:46:42 +08:00
|
|
|
|
|
|
|
|
;; core-editor.el
|
2019-05-13 11:27:34 +08:00
|
|
|
(package! better-jumper)
|
2018-05-18 07:28:40 +08:00
|
|
|
(package! dtrt-indent)
|
2018-01-22 10:37:15 +08:00
|
|
|
(package! helpful)
|
2020-01-07 04:07:13 +08:00
|
|
|
(when IS-MAC
|
|
|
|
|
(package! ns-auto-titlebar))
|
2017-02-23 13:06:12 +08:00
|
|
|
(package! pcre2el)
|
2017-07-15 05:09:48 +08:00
|
|
|
(package! smartparens)
|
2019-07-21 10:12:01 +08:00
|
|
|
(package! so-long
|
2020-01-03 10:13:31 +08:00
|
|
|
:built-in 'prefer ; included in Emacs 27+
|
2019-09-10 03:44:09 +08:00
|
|
|
;; REVIEW so-long is slated to be published to ELPA eventually, but until then
|
|
|
|
|
;; I've created my own mirror for it because git.savannah.gnu.org runs on a
|
|
|
|
|
;; potato.
|
|
|
|
|
:recipe (:host github :repo "hlissner/emacs-so-long"))
|
2020-01-09 16:04:50 +08:00
|
|
|
(package! undo-tree)
|
2020-01-05 07:10:55 +08:00
|
|
|
(package! ws-butler
|
|
|
|
|
;; Use my fork of ws-butler, which has a few choice improvements and
|
|
|
|
|
;; optimizations (the original has been abandoned).
|
|
|
|
|
:recipe (:host github :repo "hlissner/ws-butler"))
|
2020-01-07 04:07:13 +08:00
|
|
|
(unless IS-WINDOWS
|
|
|
|
|
(package! xclip))
|
2017-02-11 13:46:42 +08:00
|
|
|
|
|
|
|
|
;; core-projects.el
|
2017-02-23 13:06:12 +08:00
|
|
|
(package! projectile)
|
2017-02-19 20:03:05 +08:00
|
|
|
|
|
|
|
|
;; core-keybinds.el
|
Introduce general.el & rewrite map!
+ Now uses an overriding keymap for leader keys, so that it is always
available, even outside of normal/visual states. In insert/emacs
states, or in sessions where evil is absent, an alternative prefix is
used for leader/localleader keys. See these variables:
+ doom-leader-prefix
+ doom-leader-alt-prefix
+ doom-localleader-prefix
+ doom-localleader-alt-prefix
+ Keybinds now support alternative prefixes through the new :alt-prefix
property. This is useful for non-evil users and non-normal evil
states. By default, this is M-SPC (leader) and M-SPC m (localleader).
+ Removed +evil-commands flag from config/default (moved to
feature/evil/+commands.el).
+ config/default/+bindings.el has been split into
config/default/+{evil,emacs}-bindings.el, which one is loaded depends
on whether evil is present or not. The latter is blank, but will soon
be populated with a keybinding scheme for non-evil users (perhaps
inspired by #641).
+ The define-key! macro has been replaced; it is now an alias for
general-def.
+ Added unmap! as an alias for general-unbind.
+ The following modifier key conventions are now enforced for
consistency, across all OSes:
alt/option = meta
windows/command = super
It used to be
alt/option = alt
windows/command = meta
Many of the default keybinds have been updated to reflect this switch,
but it is likely to affect personal meta/super keybinds!
The map! macro has also been rewritten to use general-define-key. Here
is what has been changed:
+ map! no longer works with characters, e.g. (map! ?x #'do-something) is
no longer supported. Keys must be kbd-able strings like "C-c x" or
vectors like [?C-c ?x].
+ The :map and :map* properties are now the same thing. If specified
keymaps aren't defined when binding keys, it is automatically
deferred.
+ The way you bind local keybinds has changed:
;; Don't do this
(map! :l "a" #'func-a
:l "b" #'func-b)
;; Do this
(map! :map 'local "a" #'func-a
"b" #'func-b)
+ map! now supports the following new blocks:
+ (:if COND THEN-FORM ELSE-FORM...)
+ (:alt-prefix PREFIX KEYS...) -- this prefix will be used for
non-normal evil states. Equivalent to :non-normal-prefix in general.
+ The way you declare a which-key label for a prefix key has changed:
;; before
(map! :desc "label" :prefix "a" ...)
;; now
(map! :prefix ("a" . "label") ...)
+ It used to be that map! supported binding a key to a key sequence,
like so:
(map! "a" [?x]) ; pressing a is like pressing x
This functionality was removed *temporarily* while I figure out the
implementation.
Addresses: #448, #814, #860
Mentioned in: #940
2018-12-22 16:30:04 +08:00
|
|
|
(package! general)
|
2017-02-23 13:06:12 +08:00
|
|
|
(package! which-key)
|