When contexts have been defined, automatically select one at startup --
either the first whose match-function returns non-nil, or simply the
first one.
Document this, too.
Doing:
!access(...) == 0
Is equivalent to:
(!access(...)) == 0
Not:
!(access(...) == 0)
And throws this warning under clang:
mu-store.cc:77:6: warning: logical not is only applied to the left hand
side of this comparison [-Wlogical-not-parentheses]
if (!access(xpath, F_OK) == 0) {
^ ~~
mu-store.cc:77:6: note: add parentheses after the '!' to evaluate the
comparison first
if (!access(xpath, F_OK) == 0) {
^
( )
mu-store.cc:77:6: note: add parentheses around left hand side expression
to silence this warning
if (!access(xpath, F_OK) == 0) {
^
( )
It ends up doing what the author intended anyway since access() returns
-1 on error, and !-1 == 0, but just do the more obvious check and check
that we don't get 0 here with !=.
Let's not spam the poor sods who own foo.com and bar.com, or home.com
etc. Went through the various examples and changed them to use
example.com or subdomains of example.com where appropriate, even when
the domain or TLD didn't exist (yet!) for completeness.
See-Also: https://tools.ietf.org/html/rfc2606
Define mu4e-context - a structure with settings and enter/leave
functions for contexts, and some functions for switching between
contexts and auto-detecting them.
I'm using this for a rather nasty hack. When I open different bookmarks
in the mu4e-main view I want to set options for them, currently just
tweaking:
* mu4e-headers-show-threads
* mu4e-headers-include-related
* mu4e-headers-skip-duplicates
* mu4e-headers-results-limit
This is because some of my searches are *really* expensive when I
include related threads (huge batches of cron-generated E-Mails), but
some aren't. I couldn't find another way to do this. Using
mu4e-headers-mode-hook doesn't work, because we don't have access to the
search (just a variable showing the last search).
Also maybe we should be passing the actual key chord for the bookmark
here. I don't care since I look up the search string that'll be executed
and go from there, but maybe that interface would make more sense.
But whatever, this works for me, and solves a real use-case.
This 500 number was correct in v0.9.7-pre-302-g858552a, but since
v0.9.8.2-41-gc2e3eac it's been hardcoded to 1000 in the server code.
See also issue #715 and issue #716.
Right now we have this for showing the status of messages, e.g. whether
it has an attachment etc. But not for the "d", "D" etc. in the leftmost
column of the headers view.
This adds support for that, while bending over backwards to ensure that
anyone who's customized this in the past won't have their customizations
broken, i.e. like `mu4e-headers-trashed-mark` we can set this to a cons
cell of basic/fancy characters, but we also continue to support this
just being a string for existing users.
The next patch in this series adds a couple of non-ASCII characters to
be used for the trash / delete mark.
Because this was a lambda C-h m would just show "??" instead of the
function name, and the documentation would be really confusing since it
showed the deparsed lambda function instead of the function name being
called.
Fix this by refactoring both the view & headers [ and ] functions into
named functions, and make their shared logic new internal
mu4u~{headers,view}-* functions.
When user removes the In-Reply-To header, also remove the (hidden)
References header when sending the message, effectively making the
message appear at the top-level.
Mention in the doc, NEWS.