In commit 5289861109 `+workspace-delete` was
replaced by `+workspace-kill`.
The changes were not complete, though, and mu4e does not start anymore.
This patch completes the changes and should restore mu4e.
Amend: 5289861109
To be more consistent with other uses of the verb in the Emacs
ecosystem. Also done in preparation for a new +workspaces/delete command
for #7869.
Ref: #7869
mu4e-clear-caches was removed in djcb/mu@f73aad2b41, so users on
1.12.2 or so will see void-function errors until djcb/mu@770a2396de is
propagated to distro package managers, which likely won't happen
soon (esp for LTS distros).
Fix: #7703
Ref: djcb/mu@f73aad2b41
Ref: djcb/mu@770a2396de
Co-authored-by: dltacube <dltacube@users.noreply.github.com>
Now that mu4e has its own notification feature since 1.10 (and as of
this commit version 1.12 is already out), we can just use that. Much
less code to maintain.
Closes: https://github.com/doomemacs/doomemacs/issues/6896
mu4e-quit now takes an optional argument, BURY, which is a boolean that
determines whether to bury the buffer or kill it. This commit updates
the advice to reflect this change.
BREAKING CHANGE: This deprecates the IS-(MAC|WINDOWS|LINUX|BSD) family
of global constants in favor of a native `featurep` check:
IS-MAC -> (featurep :system 'macos)
IS-WINDOWS -> (featurep :system 'windows)
IS-LINUX -> (featurep :system 'linux)
IS-BSD -> (featurep :system 'bsd)
The constants will stick around until the v3 release so folks can still
use it -- and there are still some modules that use it, but I'll phase
those uses out gradually.
Fix: #7479
Previously, this was a bit confusing and didn't look quite right.
Instead, just pad the space in the temp buffer instead of fontifying it
into a button.
This commit fixes several Doom mu4e functions which are broken on later
versions of mu4e due to the variable prefix change from mu4e~ to mu4e--.
I also added them to the forwards-compatibility aliases.
BREAKING CHANGE: This commit replaces all-the-icons with nerd-fonts. Any
all-the-icons-* function calls or variable references in your private
config will break and should be replaced with their nerd-icons-*
equivalent. That said, Doom will continue to install all-the-icons for
a while, so feel free to load it if you don't want to fully commit to
the change yet.
This change is happening because nerd-icon has wider support for GUI and
TUI Emacs; has a larger, more consistent selection of symbols; plus unicode
coverage.
Fix: #7368Close: #6675Close: #7364
In the leuven theme (and possibly others), the use of
`(mode-line-emphasis bold)` results in white text on a white background,
making the shortcut keys invisible.
The original function mu4e--main-action-string uses mu4e-highlight-face,
and changing back to this fixes the problem.
I can’t tell from the git history what the reasoning for the face change
specifically was: the new function seems to have been made mainly for
changing the bullets to unicode versions.
Fix: #7010
The method for customizing +notmuch-sync-backend was changed in 19d4126
to accept a string; consequently the current example in the docs results
in an error:
user-error: Invalid notmuch backend specified: custom
Ref: 19d41262e4
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!
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.
