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
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 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.
+mu4e-lock-available seems like a potential entry-point to the mu-lock
functionality, e.g. on startup check if another Emacs process has mu4e
active, and so it might as well be turned into an autoload.
Originally this was added to have the order of attached files match the
order of mark selection. Recent usage indicates that this was either
misguided or the behaviour has changed, as this now achieves the opposite
effect --- with nreverse files are attached in reverse order. Removing
nreverse provides the expected behaviour.
With mu4e came a new face for the header view. While this is nice for
the text, it had the consequence of making the account stripe (the
vertical bar) a bit jarring. This patch fixes that behavior to make the
stripe non-italic by append `'default` to the face.
featurep! will be renamed modulep! in the future, so it's been
deprecated. They have identical interfaces, and can be replaced without
issue.
featurep! was never quite the right name for this macro. It implied that
it had some connection to featurep, which it doesn't (only that it was
similar in purpose; still, Doom modules are not features). To undo such
implications and be consistent with its namespace (and since we're
heading into a storm of breaking changes with the v3 release anyway),
now was the best opportunity to begin the transition.
Thanks to some combination of ignorance and obstinance, mu4e has thrown
compatibility to the wind and completely ignored the exitance of
define-obsolete-function-alias. Coupled with the inconsistent/partial
function renaming, this has made the mu4e 1.6⟶1.8 change particularly
annoying to deal with.
By suffering the pain of doing the mu4e author's work for them, we can
use defalias to give backwards compatibility a good shot for about 60
functions. Some mu4e~x functions are now mu4e--x, others are unchanged,
and then you've got a few odd changes like mu4e~proc -> mu4e--server and
mu4e-search-rerun. The form of message :from entries has also changed,
and a new (mu4e) entrypoint added supplanting mu4e~start.
Fix: #6511Close: #6549
Co-authored-by: Rahguzar <aikrahguzar@gmail.com>
On mac process args aren't defined, but comm is. Since comm also works
on Linux, we now check for that instead, accounting for a potential
capitalisation difference.
Modify +mu4e-set-from-address-h to account for messages with multiple
to/from headers by finding the intersection between the headers and
registered accounts.
While I'm at it, there was a rather silly typo in the when-let line
that's been corrected.
This hook should only be used when users define email aliases, or no
contexts are defined (in which case the list of personal addresses
should be used). Otherwise, the `:match-func` contexts feature is
sufficient.
This allows users to have different casing in their mu4e context names
and the corresponding directories. Since mu4e's context switching
automatically selects the letter from the context name, this allows
users to set two contexts starting with the same letter to uppercase and
lowercase variants, while leaving the directories lowercase.
The default-p argument to `set-email-account!` now works as intended.
mu4e checks the first context on startup to determine the default and
uses functions for that, so we can't really get around it by setting
the bare mu4e~context-current variable.
