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
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
Adding 'Flagged messages' to mu4e-bookmarks with attributes results in
mu4e loading failure. Change the line not to use attributes.
error in process filter: mu4e-error: [mu4e] Invalid bookmark in
mu4e-bookmarks error in process filter: [mu4e] Invalid bookmark in
mu4e-bookmarks
At some point in the original PR alerts stopped working. I've finally
tracked down why and found three components to the problem:
- I'm calling `start-process` incorrectly
- `truncate-string-to-width` is called on `nil` when no from name is
given
- mu4e-alert uses :docid to check for duplicates, which is not provided
in mu 1.6, and so :message-id must be used instead.
Because Outlook interprets 90ch as 90px ... nice job Outlook.
I also adjusted text size and padding with code snippets while we're
tweaking.
Close#5439
Having "/" at the end allows for a single backspace to remove the
directory, instead of just the last character - making it easier to
select a different location in a completing read.
It's not nice having to think of the index of the MIME part you want to
look at, it's much nicer to get a completing read with information about
those parts.
When viewing a message, in mu4e < 1.6 'A' gives actions that can be
performed on the attachments, and 'p' / 'P' save attachments. The
functions are removed in 1.6, and their nearest replacements are not
bound. I think it makes sense to actually bind them.
Mu4e 1.6 changes the signature of `mu4e-draft-open'. Since we don't care
about the args replace funcall with apply to make sure it's happy no
matter how many args it expected.
Recently org-msg gained the capability to change which exports/mime
types are sent based on the email, and a new utf-8 type. We will make
use of both of these additions.
Emails sent to an @gmail.com account may have been forwarded to a non-gmail mailbox.
Thus the current approach is over-eager.
Only checking @gmail on send, and then matching a user's maildir (not email) with
received messages is a more robust approach.
To accommodate this we switch `+mu4e-gmail-addresses' out for `+mu4e-gmail-accounts'.
Along the way `mu4e-index-cleanup' and `mu4e-index-lazy-check' customisations were
moved into the readme as a recommendation for Gmail-only users, to avoid causing
adverse effects for users who have non-gmail accounts too.
