BREAKING CHANGE: This renames the fn! macro to lambda! and fn!! to fn!.
I hadn't put much thought into their names when they were added, but now
that they're seeing more use, I've reconsidered.
The reasoning is (and I'll refer to them by their new names):
- If you're using fn!, you care more about the syntax's brevity, than if
you were using lambda!, so I wanted fn! to have the (even if slightly)
shorter name.
- lambda! decorates native lambda (with cl-function). Its old name
did not suggest that connection like other !-macros in Doom's library
do.
- Their old names implied the two macros were somehow related or that
one decorated the other. They aren't and don't.
org-download-delete doesn't accommodate a non-standard value for
org-download-link-format. Now it does.
Close: #6202
Co-authored-by: zrquan <zrquan@users.noreply.github.com>
Evil may not always be available in all buffers, and in line with the
filepath yank commands on SPC f y/Y, I thought this command could be
useful. However, I omitted a "replace buffer with paste" command because
in any editing context, evil should be available, in which case it'd be
redundant with `vigp` (or yig for yanking the buffer).
Close: #5281
Co-authored-by: Alex Palaistras <deuill@users.noreply.github.com>
When leaving org-tree-slide-mode, the window fringes are reset
fringe-mode has multiple possible types, including cons cell,
which cannot be passed directly to set-window-fringes
Adding `Cannot add [word] to any active dictionary` error to the
troubleshooting section.
I have had this problem multiple times now when I break my emacs and
wipe the `~/.config/emacs` directory and I can never remember what file
to create to get my spell check working properly.
Even though this is a bug and might be fixed in the future, I feel like
having it documented can be helpful in the short term and in the future.
Ref: #6246
'doom help' is aliased to the pseudo command ':help'. (doom-cli-find
'("doom" "help")) would return a list of all CLIs that are pertinent to
'doom help's execution, but it resolves aliases, making it unclear to
recipients of this list what the initial command was.
This requires callers resolve the CLIs themselves, but at least now the
user has the choice.
A more elegant solution will have to wait until the CLI rewrite (where
modules can supply patches for its packages, then I could hoist
org-protocol-check-filename-for-protocol into the autoloads file using
autoload cookie magic).
Fix: #6481Fix: #5997
$DOOMDIR/init.el had to be loaded earlier, so we could read the active
module list. This indirectly fixes an issue where users' literate
configs weren't being tangled on 'doom sync'.
Fix: #6479
So the doctor doesn't complain about pseudo packages, like revealjs,
which is not actually an Emacs package, we're just using straight.el to
install it for org-re-reveal.
Newer versions of project.el changed the return value of
`project-current` to a three-part list, rather than a cons cell.
centaur-tabs expects the old signature and we get a type error.
This advice ensures centaur-tabs works with old or new versions of
project, and is a temporary measure until the issue is resolved
upstream.
Ref: ema2159/centaur-tabs#181
Fix: #6280
First, removal of the old org-protocol advice needed to be updated,
because org-protocol-detect-protocol-server was renamed to
org--protocol-detect-protocol-server upstream.
Second, I only noticed now that our lazy loader for org-protocol wasn't
active until Org was loaded, which was far too late, and meant
org-protocol wasn't working out of the box. This fixes that.
Before:
$ doom ci hook commit-msg test
Error: "doom ci" expected 0 arguments, but got 1
Usage: doom ci COMMAND [ARGS...]
See 'doom h[elp] ci' or 'doom ci {-?,--help}' for documentation.
After:
$ doom ci hook commit-msg test
Error: ":before doom ci" expected 0 arguments, but got 1
Usage: doom ci hook commit-msg FILE
See 'doom h[elp] ci hook commit-msg' or 'doom ci hook commit-msg {-?,--help}' for documentation.
- :before ci will try to load $REPOROOT/ci.el or $DOOMDIR/ci.el. It
finds $REPOROOT by calling `git`, but doesn't handle errors. Now it
does.
- Because &rest was in :before ci's argspec, :before ci * subcommands
would be inaccessible (not that any exist atm, though).
- Let the user know when it finds the project's ci.el.
To understand what's going on here, understand this: this is a regular
CLI command:
(defcli! (doom sync) () ...)
And this is a pseudo command:
(defcli! (:before doom sync) () ...)
If a pseudo command is aliased to another pseudo command:
(defcli! (:before doom (foo bar baz)) ...)
In which case, ':before doom bar' and ':before doom baz' are aliases for
':before doom foo', there was a bug that cut out the keyword, so in
actuality, ':before doom {bar,baz}' were aliased to 'doom bar'.
This fixes that, and the peculiar issue of 'doom purge' executing 'doom
build' due to this, living in core/cli/packages.el:
(defcli! (:before (build b purge p)) (&context context)
(require 'comp nil t)
(doom-initialize-core-packages))
Ref: https://github.com/doomemacs/doomemacs/issues/4273#issuecomment-1159610824
If you type an unrecognized command, you get an "Error: unrecognized
command X" error, then a list of similar commands, followed by a
recommendation to check out 'doom help Y' or 'doom --help Y', where Y is
the nearest recognized parent command. E.g. 'doom ci blah' is an unknown
command, but 'doom ci' is known, therefore Y = 'doom ci'.
This fix ensures that Y is properly resolved.
Amend: 6c0b7e1530
Before:
$ doom help help
Usage: COMMAND [ARGS...]
TODO
TODO
After:
Usage: doom help [-g|--no-global] [--manpage] [--commands]
[--synopsis|--subcommands|--similar|--envvars|--postamble] [--]
COMMAND [ARGS...]
Show documentation for a Doom CLI command.
OPTIONS:
-g, --no-global
Hide global options.
--manpage
Generate in manpage format.
--commands
List all known commands.
--synopsis, --subcommands, --similar, --envvars, --postamble
Show only the specified sections..
Amend: 6c0b7e1530
Some packages (primarily vterm, evil-collection, and with-editor) end up
hanging their native compilation process. In vterm's case it's because
it invisibly prompts to compile its module then waits forever for user
input that'll never come. I haven't figured out why it happens for the
others though.
In any case, since the workaround is to simply kill these processes and
carry on, I added this timeout mechanism to do it for you (timing out
after 30s of no movement). A more elegant solution will have to wait
until the rewrite of our package manager.
Fix: #5592
