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.
+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.
It's a bit silly to just unconditionally widen the current frame when
you could have the mu4e headers view in another frame entirely. Instead
we can look for the mu4e headers buffer, and only widen frames where it
is the active buffer.
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.
- Deprecates the doom-private-dir variable in favor of doom-user-dir.
- Renames the pseudo category for the user's module: :private -> :user.
- Renames the doom-private-error error type to doom-user-error.
Emacs uses the term "user" to refer to the "things" in user space (e.g.
user-init-file, user-emacs-directory, user-mail-address, xdg-user-dirs,
package-user-dir, etc), and I'd like to be consistent with that. It also
has the nice side-effect of being slightly shorter. I also hope
'doom-user-error' will be less obtuse to beginners than
'doom-private-error'.
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.
Some of our comments/docs can come off as disparaging or snide. They're
glimpses of unfiltered frustration or snarky rubber ducking gone too
far, something I can totally sympathize with, as a scatterbrained
tinkerer, unwittingly made responsible for a lot of work that isn't mine
because of Doom's position as a middleman. But now that Doom has a
veritable userbase, I'd like to hold it to a higher standard.
Light-hearted banter and aired grievances in our source code,
documentation, or community are fine if focused on the problem or the
personal/shared experiences of the community (things that offer value or
amusement to others), but it is never acceptable to attack people or
their efforts. Especially not the very people on whose shoulders Doom
stands.
I sincerely apologize if these have offended you.
Amend: b07614037f
I've omitted docs/*.org from this merge, as there is still work left to
do there, but I am pushing the module docs early so folks can benefit
from the new docs sooner.
+notmuch/update would create an additional window that outlasts the
update process. Instead, delete the window and bury the buffer, so that
it may be read later.
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>
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
