djcb/mu

We ship the few macros we need or make them conditional

Tell base64-encode-string not to include newlines.

Use base-64 for now.

Making it sign by default is a bit too aggressive.

Update dependency information.

some distros -- notably Ubuntu 16.04 -- do not include
ax_cxx_compile_stdcxx_14.m4 in their autotools-archive package (since
the macro is too new).

This breaks the compilation since we need that macro to get the correct
c++14 flags. So, let's add them ourselves, so users don't have to shop
around for these macros themselves.

and just that.

fix quoting issues with mu4e

don't require anything post c++14

fix macro usage

And explicitly raise an error if the right compiler is not found.

Ensure there's no non-' ' whitespace, and no trailing/leading spaces.

mu4e: Allow to set the reply policy in a smart manner

Update documentation for new query parser

maildirs with spaces

note the new query parser doc

Add some notes about the new query parser, and add a mu-query manpage.

update for the new query parser

mu's query parser is the piece of software that turns your queries
into something the Xapian database can understand. So, if you query
"maildir:/inbox and subject:bla" this must be translated into a
Xapian::Query object which will retrieve the sought after messages.

Since mu's beginning, almost a decade ago, this parser was based on
Xapian's default Xapian::QueryParser. It works okay, but wasn't really
designed for the mu use-case, and had a bit of trouble with anything
that's not A..Z (think: spaces, special characters, unicode etc.).

Over the years, mu added quite a bit of pre-processing trickery to
deal with that. Still, there were corner cases and bugs that were
practically unfixable.

The solution to all of this is to have a custom query processor that
replaces Xapian's, and write it from the ground up to deal with the
special characters etc. I wrote one, as part of my "future, post-1.0
mu" reseach project, and I have now backported it to the mu 0.9.19.

From a technical perspective, this is a major cleanup, and allows us
to get rid of much of the fragile preprocessing both for indexing and
querying. From and end-user perspective this (hopefully) means that
many of the little parsing issues are gone, and it opens the way for
some new features.

From an end-user perspective:
- better support for special characters.
- regexp search! yes, you can now search for regular expressions, e.g.
      subject:/h.ll?o/
  will find subjects with hallo, hello, halo,  philosophy, ...

  As you can imagine, this can be a _heavy_ operation on the database,
  and might take quite a bit longer than a normal query; but it can be
  quite useful.