Smartparens creates a conditional keybind on C-g when its overlays are
present (whether or not they're visible). This causes confusion when
evil users are forced to press C-g twice to exit insert mode.
If called with a C-u prefix, `doom/help-modules' now browses the module's
directory instead of opening its documentation. This exposes the VISIT-DIR
argument to `interactive' use.
febf960 introduced a regression, in that it caused `smartparens-mode' to
no longer be enabled for `evil-ex'. This is because the latter doesn't
call `read--expression', but calls the minibuffer directly instead.
Return `doom-init-smartparens-in-minibuffer-maybe-h', enabling
`smartparens' for `evil-ex'. The hook responsibly for enabling it in
`eval-expression-minibuffer-setup-hook' was renamed to
`doom-init-smartparens-in-eval-expression-h', since otherwise the naming
would have been awkward.
Also explicity enable `smartparens-mode' instead of toggling it.
This should make more exotic symlink config setups viable, but should
also speed up a few internal operations. There are too many possible
symlink configurations to support them all, however.
+ Cache package list
+ Show "generating package list" message the first time (better ux)
+ Display location of package files in package information
+ Turn links/file paths into buttons
+ Add link to module readmes (if any)
Mentioned in #4406
`doom-init-smartparens-in-minibuffer-maybe-h' is responsible for enabling
`smartparens' in the minibuffer, which it does by checking `this-command'.
However, the list of commands doesn't include `edebug-eval-expression',
preventing the mode from being enabled for it.
Fix this by enabling `smartparens' in `eval-expression-minibuffer-setup-hook',
unconditionally, which means that anything using `interactive' "x" or
`read--expression' will work correctly.
The upgrade process leaves a left over ref:
```
$ git branch
..
_upgrade_HEAD
..
```
This commit deletes that.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
`doom-cli-upgrade` calls `git fetch` to fetch remote branch and tags and
check output code of this command to complain when it failed.
It fails when remote server isn't available that is good.
But it also fails when it can't to fast-forward a branch that will be
used to upgrade doom-emacs.
The last case created a loop and the only way to broke this loop is
remote a branch that should be used for upgrade.
Unfortunately user has no idea about branch name and can't do anything,
just enjoy crash with `Failed to fetch from upstream` message.
This commit added `--force` flag to `git fetch` that forces it to
overwrite branch that is used to upgrade that prevent such loop.
It also fixed https://github.com/hlissner/doom-emacs/issues/4346
This is commonly used in Emacs packages to resolve to a location in
`~/.emacs.d`, as storage or a cache. Rather than addressing each
file/directory variable as they are encountered, better to address this
at the source.
Also: this makes some file/directory settings redundant, so they were
removed.
Closes#4347
Previously, `doom upgrade` would emit:
```
New revision: fatal: amb (fatal: ambiguous argument '_upgrade/HEAD': unknown revision or path not in the working tree.
Use '--' to separate paths from revisions, like this:
```
It appears it's not possible to remote revisions with
`<remote>/<revision>`. Instead, we fetch the upgrade remote into a named
revision and then use it.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
When compiling standalone files such as `init.el`, instead of saying
that it belongs to module `nil nil`, say that these files are
standalone.
Signed-off-by: Rudi Grinberg <me@rgrinberg.com>
Renamed `comp-deferred-compilation-black-list` to
`comp-deferred-compilation-deny-list`.
Removed the `late` load flag which is no longer required.
Added a check against the deny list when compiling all Elisp on the
load-path, so we don't inadvertently compile something we shouldn't.
Added compatibility shims to ease transition from older builds of
native-comp.
