+ :sh can now be fed commands to run immediately, e.g. :sh cd %:P to
start from the current project root.
+ Eshell will spawn a new eshell on every split. This can be controlled
via `+eshell-enable-new-shell-on-split'
+ Eshell can be configured to kill the window when you kill the eshell
process. This is disabled by default. See
`+eshell-kill-window-on-exit'. Some commands ignore this, like the
quit-and-close command (I alias this to "q").
+ eshell-directory-name has been moved to doom-etc-dir/eshell. It will
seem like eshell has forgotten all your history, but you can move
~/.eshell (or ~/.doom.d/eshell) to ~/.emacs.d/.local/etc/eshell and
you'll be fine.
+ eshell-aliases-file has been moved to ~/.doom.d/eshell_aliases by
default.
+ Automatic writing to eshell-aliases-file has been disabled. No shell
so aggressively persists aliases. You may maintain it yourself, or use
the new +eshell-aliases variable to customize eshell from Doom.
+ C-s now invokes a history search with ivy/helm.
+ C-c s and C-c v split horizontally and vertically. Inspired by tmux.
+ C-c x kill the current eshell and its window. Inspired by tmux.j
+ New set-eshell-alias! autodef for defining your own aliases.
+ +eshell/open-workspace has been replaced with +eshell/open-fullscreen.
+ Added the "cd-to-project" command. I suggest you alias it.
The error handlers were a little too effective. They obscured a large
chunk of the stacktrace after errors, even in debug mode. This fixes
that and ensures backtraces in debug mode are more helpful.
This is in preparation for general.el integration coming in 2.1.1. It is
very likely that map! will change (and even more, be split into several
macros). Not much, but change none-the-less. Specifically, the state
keywords (e.g. :nvi, :n, :i) will be removed in favor of a :state
property that takes a list, e.g. (normal visual insert).
In any case, both map! and general are also relatively expensive
compared to define-key and evil-define-key* (and the new define-key!
macro), so use that when we can.
This also means changes to either API won't affect Doom's modules in the
long term.
