Global options were omitted in help output for subcommands before this
fix. This caused #6533, where the user was unable to find the correct
option to suppress prompts because 'doom upgrade --help' would not show
--force/-!, but 'doom --help' would. Still, it's unreasonable to expect
the user to know this beforehand.
Ref: #6533
The global options (like --debug and --pager) weren't recognized for
pseudo command like :help and :version (in particular, rendering --pager
ineffective).
Fix: #6526
--pager incorrectly expected a boolean argument, when it should accept
any arbitrary pager command (set to a blank string to disable the
pager).
Ref: #6526
Doom changes user-emacs-directory (see 46844b5 for explanation), so
doom-emacs-dir should be used to refer to your $EMACSDIR instead.
Fix: #6530
Ref: 46844b55de
ansi-color-compilation-filter wasn't introduced until Emacs 28, so this
removal was too hasty, but should be reconsidered when we drop 27.x
support.
Fix: #6515
Revert: 2f7171bf8a
doom-debug-p and doom-interactive-p have always been intentionally
redundant, because changing the variables they replaced had other
side-effects, which made writing tests for them difficult. Since our
new (yet unpublished) tests lean heavily toward integration testing more
than unit testing, this becomes an implementation detail.
And doom-init-p's only use was refactor out at some point in the past,
so it's no longer used.
Also done to reduce Doom's footprint, in general.
Messages from the current day do not fit with the current width since
they are formatted as times (Ex: "05:17:23 PM"). The increase to 12
matches the mu4e defaults.
Amend: d1ba626a2a
- Add comments to doom-cli-context-parse.
- Simplify/inline code here and there.
- Remove sacrifice to appease byte-compiler.
Thanks to a346928 there's no need to appease the byte-compiler with this
eval-when-compile hackery.
Ref: a34692826f18
This regression was introduced in 6c0b7e1, preventing the debugger from
printing straight.el's process log when a straight.el error occurs.
Instead, it would print a less-than-helpful backtrace.
Amend: 6c0b7e1530
I've removed these CLI properties because they were either
unused (:deprecated and :since) or poorly implemented (:stub and
:obsolete). And I'd rather have fewer magical properties, and instead
delegate these roles to the defobsolete! and (new) defstub! macros.
Also, in the future, the help API will ascertain :since dynamically, so
it won't be very useful.
In summary:
- Use defstub! instead of :stub
- Use defobsolete! instead of :obsolete or :deprecated
- This removes the doom-cli-deprecated-error type (it's not really an
error to begin with).
- Removes :stub, :obsolete, :deprecated, and :since
doom-cli-context-path stores the path taken to get to the current
command. For example, given:
(defcli! (doom boop) () ...)
(defcli! (doom baz) () (call! '(boop)))
(defalias! (doom bar) (doom baz))
(defalias! (doom foo) (doom bar))
(run! "doom" "foo")
Then the doom-cli-context-path by 'doom boop' will be:
Before this commit: ((doom baz))
After this commit: ((doom baz) (doom bar) (doom foo))
These are autodefs, meaning they should be defined whether or not the
containing module is enabled, but they should no-op when it's disabled,
by defining a no-op macro with the same name. However, lsp! and
tree-sitter! are meant to be used as hooks, and you can't use macros as
hooks, so you get void-function errors when they are used as such.
This ensures they are properly defined as no-op functions in those
cases. I.e.
;;;###autodef FORM
FORM is used instead of a no-op macro if the parent module is disabled.
I use a shortcut like this to autoload multiple (different) CLIs living
in the same file:
(defautoload! ((foo bar baz)) "file")
However, this creates premature aliases between autoloaded CLIs. When
'baz' is invoked, instead of loading "file", it resolves to 'foo'
first *then* loads it, causing 'foo' to be executed instead of 'baz'.
This commit fixes that.
Also, minor refactor: I removed the plist argument from a
doom-cli-command-normalize call because it wasn't needed or useful to
the consumer of its return value.
Amend: d226946f59
This killed the script prematurely (without displaying the error) if
Emacs failed to execute. In versions prior to bash 4, set -e would not
terminate the script if a non-zero exit code occurred within a subshell,
but it will in bash 4+.
In any case, we don't need this fallback to begin with. The script
handles its errors sufficiently otherwise.
Emacs 29 introduces a new command: restart-emacs, which clashes with the
more featureful restart-emacs package that Doom installs to manage the
session. Fortunately, the built-in one is defines in files.el, which is
eagerly loaded at startup, so as long as the third-party one is
loaded (at some point), it shouldn't be a problem.
Fix: #6492
A little more time and space gained by cutting out seq entirely and
pre-generating the argument lookup table. At least, in uncompiled use
cases.
The original implementation used regexp to lookup arguments, which
was (relatively) expensive. By comparison, using `assq` is *much*
faster, especially for datasets this small; and more so when I get
around to byte-compiling Doom's core (assq has its own byte-compiler
opcode).
- Reduces allocations by avoiding copies produced by reverse and seq,
and by avoiding a closure.
- Reduces runtime by avoiding the overhead of seq's generics.
I had missed the fact that -Q implies not only
--no-site-file (intended), but --no-site-lisp (unintended). Without the
latter, no site-lisp directory is left in load-path, and any attempt to
load it after-the-fact (which I do in core-cli.el) will fail. Thanks to
@yamanq for noticing this!
Fix: #6473Fix: #4198
Co-authored-by: Yaman Qalieh <yamanq@users.noreply.github.com>
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.
