The --entire-thread option in notmuch-show.c defaults to true when
format=json. Previously there was no way to turn this off. This patch
makes it respect --entire-thread=false.
To do this the patch moves the --entire-thread option to be a keyword
option using the new command line parsing to allow the existing
--entire-thread to keep working.
All formats except Json can output empty messages for non
entire-thread, but in Json format we output "null" to keep the other
elements (e.g. the replies to the omitted message) in the correct
place.
This changes the parsing for "keyword" options so that if the option
is specified with no argument the argument is parsed as if it were
passed an empty string. This make it easier to add options to existing
boolean arguments (the existing --option can default to TRUE).
Some C compilers are stricter when it comes to (tentative) definition
of a variable -- in those compilers introducing variable without 'extern'
keyword always allocates new 'storage' to the variable and linking all
these modules fails due to duplicate symbols.
This is reimplementation of Charlie Allom's patch:
id:"1336481467-66356-1-git-send-email-charlie@mediasp.com",
written originally by Ali Polatel. This version has
more accurate commit message.
Allow the user to pipe the attachment somewhere. Bound to '|' on the
attachment button.
Signed-off-by: Jameson Graef Rollins <jrollins@finestructure.net>
Previously, the timestamp at the beginning of the FCC unique maildir
name was derived incorrectly, thanks to an integer overflow. This
changes the derivation of timestamp to use a float, and so will get
the number correct at least until 2038. (It is still formatted with
"%d" so it will show up as an integer.) Should we need to change it in
the next 26 years to take the unix millenium into account, it will be
invisible to users.
This change is mostly a question of consistency, since the unique name
is arbitrary anyway. But since most people use timestamps, and that was
the original intention here as well, we might as well.
Signed-off-by: Jesse Rosenthal <jrosenthal@jhu.edu>
Previously, notmuch new only synchronized maildir flags to tags for
files with a maildir "info" part. Since messages in new/ don't have
an info part, notmuch would ignore them for flag-to-tag
synchronization.
This patch makes notmuch consider messages in new/ to be legitimate
maildir messages that simply have no maildir flags set. The most
visible effect of this is that such messages now automatically get the
unread tag.
Previously, we synchronized flags to tags for any message that looked
like it had maildir flags in its file name, regardless of whether it
was in a maildir-like directory structure. This was asymmetric with
tag-to-flag synchronization, which only applied to messages in
directories named new/ and cur/ (introduced by 95dd5fe5).
This change makes our interpretation stricter and addresses this
asymmetry by only synchronizing flags to tags for messages in
directories named new/ or cur/. It also prepares us to treat messages
in new/ as maildir messages, even though they lack maildir flags.
This way notmuch_message_maildir_flags_to_tags can call it. It makes
more sense for this to be just above all of the maildir
synchronization code rather than mixed in the middle.
Currently, notmuch new only synchronizes maildir flags to tags for
files that have an "info" part. However, in maildir, new mail doesn't
gain the info part until it moves from new/ to cur/. Hence, even
though mail in new/ doesn't have an info part, it is still a maildir
message and thus has maildir flags (though none of them set).
The most visible effect of not synchronizing maildir flags for
messages in new/ is that newly delivered messages don't get the unread
tag (unless it is assigned by some other mechanism, like new.tags).
This patch does *not* modify the test for messages in cur/ that do not
have an "info" part. Unlike a message in new/, a message in cur/
without an info part is no longer a maildir message, and thus
shouldn't be subject to maildir flag synchronization.
This has the affect of lazily creating the crypto contexts only when
needed. This removes code duplication from notmuch-show and
notmuch-reply, and should speed up these functions considerably if the
crypto flags are provided but the messages don't have any
cryptographic parts.
Use this flag rather than depend on the existence of an initialized
gpgctx, to determine whether we should verify a multipart/signed. We
will be moving to create the ctx lazily, so we don't want to depend on
it being previously initialized if it's not needed.
This new structure, notmuch_crypto_t, keeps all relevant crypto
contexts and parameters together, and will make it easier to pass the
stuff around and clean it up. The name of the crypto context inside
this new struct will change, to reflect that it is actually a GPG
context, which is a sub type of Crypto context. There are other types
of Crypto contexts (Pkcs7 in particular, which we hope to support) so
we want to be clear.
The new crypto.c contains functions to return the proper context from
the struct for a given protocol (and initialize it if needed), and to
cleanup a struct by releasing the crypto contexts.
gmime 2.4 defines GMimeCipherContext, while 2.6 defines
GMimeCryptoContext. typedef them both to notmuch_crypto_context_t to
cover this discrepancy and remove a bunch of #ifdefs.
If any of the forked process exits with nonzero value, terminate
current operation -- nonzero exit value indicates failure and
then there is no point continuing.
Changes to devel/uncrustify.cfg:
* Updated header comment to state this is config file for *notmuch*.
* Added comment about the reason of 'type' keyword used.
* Added some more custom types woth 'type' keyword.
* Have (every) multiline comment lines start with '*'.
It was decided in the thread starting at [0] that it is okay for
notmuch to use 'cl runtime functions. However, by default, these
produce byte compiler warnings. This suppresses those using
file-local variables.
[0] id:"m262g864dz.fsf@wal122.wireless-pennnet.upenn.edu"
Without proper quoting the DEFAULT_IFS was getting set incorrectly,
which was causing problems with the storage of some variables later in
the script. Quoting fixes the problem.
When asked for interactive help, lookup notmuch-search-terms(7)
instead of notmuch(1). Syntax of notmuch queries used to be described
in the latter, but has recently been moved to the former.
Closes: #675073 (in the Debian BTS)
This reverts commit 82b73ffd73.
Only leave the copyright changes.
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com>
(cherry picked from commit 35cb1c95cc)
Add tests for picking up user's From address from fallback headers
Envelope-To, X-Original-To, and Delivered-To.
Signed-off-by: Jani Nikula <jani@nikula.org>
Add another fallback header Delivered-To for guessing the user's from
address for notmuch reply before using the Received
headers. Apparently some MTAs use Delivered-To instead of
X-Original-To (which already exists as a fallback).
Reported-by: Michael Hudson-Doyle <michael.hudson@canonical.com>
Signed-off-by: Jani Nikula <jani@nikula.org>
Since starting at the top of a directory tree and recursing within
that tree are now identical operations, there's no need for both
add_files and add_files_recursive. This eliminates add_files (which
did nothing more than call add_files_recursive after the previous
patch) and renames add_files_recursive to add_files.
Previously, add_files_recursive could have been called on a symlink to
a non-directory. Hence, calling it on a non-directory was not an
error, so a separate function, add_files, existed to fail loudly in
situations where the path had to be a directory.
With the new stat-ing logic, add_files_recursive is always called on
directories, so the separation of this logic is no longer necessary.
Hence, this patch moves the strict error checking previously done by
add_files into add_files_recursive.
This moves our logic to get a file's type into one function. This has
several benefits: we can support OSes and file systems that do not
provide dirent.d_type or always return DT_UNKNOWN, complex
symlink-handling logic has been replaced by a simple stat fall-through
in one place, and the error message for un-stat-able file is more
accurate (previously, the error always mentioned directories, even
though a broken symlink is not a directory).
