In Emacs 28+, the mode-name in emacs-lisp-mode is "ELisp/X" (where X = d
or l depending on lexical-binding). I find this much more useful than
"Emacs-Lisp" in <=27.x or our static replacement "Elisp".
Permit `;;* ...` be recognized by imenu and outline-minor-mode (and
outline's commands). This also patches Lispy to reflect this new
configuration (if :lang emacs-lisp is active).
Close: #6732
Co-authored-by: LemonBreezes <LemonBreezes@users.noreply.github.com>
Ensure that highlight-indent-guides-auto-set-faces is called when the
active theme and frame has been initialized (particularly tricky in
daemon sessions). With this assurance, we don't need to suppress its
errors anymore.
Close: #6900
Co-authored-by: Sleepful <Sleepful@users.noreply.github.com>
use-package evaluates :preface *before* :when, so the two lsp! hooks
would run unconditionally, causing errors and warnings when opening a
haskell-mode buffer.
*
modules/lang/haskell/config.el (haskell-literate-mode-local-vars-hook):
add lsp! to hook.
Leave it to modeline modules, plugins, and/or the user to support this
plugin, rather than impose winum's (rather destructive) side-effects on
them all.
The add-node-modules-path package calls `npm bin` to locate the
node_modules/.bin, and does so while invoking the user's $SHELL, which
can be very expensive depending on the user's shell configuration,
possibly adding seconds to the startup time of any JS/TS file.
To mitigate this, I replace the package with a much faster, and in-house
heuristic. Folks with more complex needs should be using direnv anyway.
Fix: #6878
The current config is kinda confusing, it uses the same symbol for both
forwarded/passed mails and replied mails. FontAwesome provides a nice
icon for "reply", why not use it!
For some reason, the transient-append-suffix adding magit-worktree back
to magit-dispatch — after its potential replacement by
magit-gitflow-popup — was having no effect. (It does when moved into
(after! magit-gitflow), so the issue must have something to do with when
transient-append-suffix is called.) magit-worktree wasn't appearing in
the magit-dispatch popup when magit-gitflow was enabled, nor was the '*'
keybind for magit-worktree in effect outside (or inside) the popup,
unlike '%' for magit-gitflow-popup.
Replace the ineffectual transient-append-suffix with a normal and visual
mode keybind for magit-worktree in magit-mode-map (and move the
unconditionally defined keybind for magit-gitflow-popup into (after!
magit-gitflow)). Also, append the magit-gitflow-popup transient suffix
to magit-worktree instead of replacing it, so that the latter still
appears in magit-dispatch (though under the original keybind 'Z' — which
isn't really an issue, since evil-collection-magit doesn't seem to
update the keybinds of any of the other commands accessible from
magit-dispatch — but also callable with '*').
C-S-s while company is completing shoudl bring up the results in your
completion framework of choice (ivy, helm, vertico, etc), but failed to
do so for vertico (for any completion backend besides company-capf
perhaps).
Some time ago I noticed the cooperative lock file management wasn't
working as I remember. I forget what exactly I was thinking, but
basically I've poked at the code until it seems to work better.
In 4d9ea6853b I reacted to a either a change that I presume occurred
in org-msg at some point, or behaviour originally unnoticed, that led to
bulk-selected files being attached in reverse. Further investigation has
indicated that this isn't actually making attachment order work as
expected, just hiding the reverse behaviour from bulk-attachment. The
better approach is to keep the dired mark reversal, and change
org-msg-attach-attach to add new files to the end, not the start, of the
list of attachments.
There are two changes to the default optional read-file-name arguments
that should be made for the purpose of attaching files:
1. The optional MUSTMATCH argument should be set, as one can't exactly
attach non-existent files.
2. The INITIAL argument should be set to the empty string so that if
default-directory is customised for some reason or another that
selecting it leads to the expected directory being selected.
Without INITIAL or DEFAULT-FILENAME being specified, the current file
path will be used, which is never desirable as this is simply a path
to the message buffer.
Replace the rather crude "don't do anything if already in a mu4e-y
buffer" behaviour with a more refined approach that tries to find the
live mu4e buffer likely of the most interest and switch to that, before
calling (mu4e) if no such buffer is found.
Occurs during non-interactive startup of the user's config (e.g. 'doom
doctor'), while :ui (modeline +light) is enabled.
This is a makeshift solution until I get around to finishing the +light
feature.
Where f9201eb introduced a general context system, this one introduces
one for modules, to simplify our let-bind game when interacting with
modules, and to more efficiently expose module state to modulep! (which
gets called at runtime a great deal, so its performance is important).
* lisp/doom-lib.el (doom-log): simplify macro and introduce
doom-inhibit-log variable.
* lisp/doom-modules.el (modulep!): fix reported file path if modulep!
fails to find the local module.
* lisp/lib/debug.el (doom-debug-variables): disable doom-inhibit-log
when debug mode is on.
Ref: f9201eb218
Introduces a system to announce what execution contexts are active, so I
can react appropriately, emit more helpful logs/warnings in the case of
issues, and throw more meaningful errors.
* bin/doom: load module CLIs in the 'modules' context.
* lisp/cli/doctor.el: load package files in 'packages' context.
* lisp/doom-cli.el:
- (doom-before-init-hook, doom-after-init-hook): trigger hooks at the
correct time. This may increase startup load time, as the benchmark
now times more of the startup process.
- (doom-cli-execute, doom-cli-context-execute,
doom-cli-context-restore, doom-cli-context-parse,
doom-cli--output-benchmark-h, doom-cli-call, doom-cli--restart,
doom-cli-load, run!): remove redundant context prefix in debug logs,
it's now redundant with doom-context, which doom-log now prefixes
them with.
* lisp/doom-lib.el (doom-log): prefix doom-context to doom-log output,
unless it starts with :.
* lisp/doom-packages.el (package!, doom-packages--read): throw error if
not used in a packages.el file or in the context of our package
manager.
* lisp/doom-profiles.el (doom-profile--generate-init-vars,
doom-profile--generate-load-modules): use modules doom-context instead
of doom-init-time to detect startup.
* lisp/doom-start.el (doom-load-packages-incrementally-h): move function
closer to end of doom-after-init-hook.
* lisp/doom.el:
- (doom-before-init-hook, doom--set-initial-values-h,
doom--begin-init-h): rename doom--set-initial-values-h to
doom--begin-init-h and ensure it runs as late in
doom-before-init-hook as possible, as that is the point where Doom's
"initialization" formally begins.
- (doom-after-init-hook): don't trigger at the end of command-line-1
in non-interactive sessions. This will be triggered manually in
doom-cli.el's run!.
* lisp/lib/config.el (doom/reload, doom/reload-autoloads,
doom/reload-env): use 'reload' context for reload commands.
* modules/lang/emacs-lisp/autoload.el (+emacs-lisp-eval): use 'eval'
context.
* modules/lang/org/config.el: remove doom-reloading-p; check for
'reload' doom context instead.
