When composing a reply, notmuch-mua-reply attempts to cite the
the original message by inserting it before the user signature, if
one is present. The existing method used to search the signature
separator backward from the end of the buffer and then move one
line up. In case of variable `message-signature-insert-empty-line'
being nil this caused point to go to the beginning of
'--text follows this line--'
separator line, and citation was inserted there.
This change checks the value of `message-signature-insert-empty-line'
and doesn't move point if that is nil. Additional narrowing to
the body region ensures that point never goes to the separator line
(or beyond).
`message-signature-setup-hook' or `message-setup-hook' may already have
added some other content to the message body, therefore using simply
(message-goto-body) to move point to the beginning of body might lead
to unexpected results.
Original patch from "Geoffrey H. Ferrari", continued with iterations
from Jani and Mark.
If any of the tests in our test system is not passing the execution
of the test suite completes with nonzero exit value.
It is better to rely on the exit value of the test system instead
of some arbitrary strings in test output (or use both).
In reply, insert quotable parts using notmuch-show-insert-bodypart
instead of calling notmuch-mm-display-part-inline directly to render
the quoted parts as they are rendered in show view.
We use a temp buffer to not leak text properties from the show
renderer into the reply. This way we also don't need to worry about
narrowing or point placement. Credits to Mark Walters
<markwalters1009@gmail.com> and Austin Clements <amdragon@MIT.EDU> for
getting this part straight.
The notable change is that replies to text/calendar parts quote the
pretty printed output of icalendar-import-buffer rather than the ugly
raw vcalendar.
notmuch_message_tags_to_maildir_flags() unconditionally moves messages from
maildir directory "new/" to maildir directory "cur/", which makes messages lose
their "new" status in the MUA. However some users want to keep this "new"
status after, for instance, an auto-tagging of new messages.
However, as Austin mentioned and according to the maildir specification,
messages living in "new/" are not allowed to have flags, even if mutt allows it
to happen. For this reason, this patch prevents moving messages from "new/" to
"cur/", only if no flags have to be changed. It's hopefully enough to satisfy
mutt (and maybe other MUAs showing the "new" status) users checking the "new"
status.
Changelog:
* v2: Fix bool type as well as NULL returned despite having no errors (Austin
Clements)
* v4: Tag the related test (contributed by Michal Sojka) as working
Signed-off-by: Louis Rilling <l.rilling@av7.net>
[Condition for keeping messages in new/ was extended to satisfy all
tests from the previous patch. -Michal Sojka]
[Added by David Bremner, to keep the tests passing at each commit]
update insert tests for new maildir synchronization rules
As of id:1355952747-27350-4-git-send-email-sojkam1@fel.cvut.cz
we are more conservative about moving messages from ./new to ./cur.
This updates the insert tests to match
As mentioned by Jani Nikula in id:87vcccp4y3.fsf@nikula.org, some cases
of maildir synchronization are not covered by our tests. Let's add the
missing tests.
Some MUA's like mutt show the difference between "new" emails living in maildir
directory new/, and "old" emails living in maildir directory cur/. However
notmuch tag unconditionally moves selected messages from new/ to cur/, even if
no maildir synchronized tag is changed.
While maildir specification forbids messages with tags living in new/, there is
no need to move messages to cur/ when no maildir synchronized tag is changed.
Thus notmuch can remain transparent with respect to other MUA's.
[ Edited commit log to better describe the intended changes, and tag the
test as broken until the actual changes are implemented -- Louis Rilling ]
Signed-off-by: Louis Rilling <l.rilling@av7.net>
[ Converted to use test_subtest_known_broken, David Bremner ]
This variable is essentially unused: it was only used for making sure
it itself got reset after a refresh of the buffer.
It did this by passing an unnecessary argument to notmuch-pick-worker
so remove that too.
This adds functions to go to the previous or next thread to
pick. Prev-thread behaves similarly to prev-message in show: if you
are on the top line of a thread it will go to the top of the previous
thread, otherwise it will go to the top of the current thread. Next
thread will always go to the top of the next thread (or the end of
buffer). These are bound to "M-p" and "M-n" by default (matching the
bindings in show).
Previously pick had no actions based on the entire thread: this adds
some. Note in this version '*' is bound to `tag thread' which is not
consistent with search or show. However it still might be the most
natural thing (as it is similar to running * in the show pane).
Previously notmuch-pick had no thread based functionality. This adds a
macro to iterate through all messages in a thread. To simplify this it
adds a text-property marker to the first message of each thread.
Long story short, fix build on recent (3.2+) clang.
The long story for posterity follows.
gcc 4.6 added new warnings about structs with greater visibility than
their fields. The warnings were silenced by adjusting visibility in
commit d5523ead90
Author: Carl Worth <cworth@cworth.org>
Date: Wed May 11 13:23:13 2011 -0700
Mark some structures in the library interface with visibility=default attribute.
Later on,
commit 3b76adf9e2
Author: Austin Clements <amdragon@MIT.EDU>
Date: Sat Jan 14 19:17:33 2012 -0500
lib: Add support for automatically excluding tags from queries
changed visibility of struct _notmuch_string_list for the same reason, and
commit 1a53f9f116
Author: Mark Walters <markwalters1009@gmail.com>
Date: Thu Mar 1 22:30:38 2012 +0000
lib: Add the exclude flag to notmuch_query_search_threads
split the struct _notmuch_string_list and its typedef
notmuch_string_list_t as a way to make a forward declaration for
_notmuch_thread_create().
The subtle difference was that the struct definition now had 'visible'
in it, while the typedef didn't, and it was within the #pragma GCC
visibility push(hidden) block. This went unnoticed, as the then common
versions of clang didn't care about this.
A later change in clang (I did not dig into when this change was
introduced) caused the following error:
CXX -O2 lib/database.o
In file included from lib/database.cc:21:
In file included from ./lib/database-private.h:33:
./lib/notmuch-private.h:479:8: error: visibility does not match previous declaration
struct visible _notmuch_string_list {
^
./lib/notmuch-private.h:67:33: note: expanded from macro 'visible'
^
./lib/notmuch-private.h:52:13: note: previous attribute is here
^
1 error generated.
make: *** [lib/database.o] Error 1
This is slightly misleading due to the reference to the #pragma. The
real culprit is the typedef within the #pragma.
We could just add 'visible' to the typedef, or move the typedef
outside of the #pragma, and be done with it, but juggle the
declarations a bit to accommodate moving the typedef back with the
struct, and keep the visibility attribute in one place.
The problem was originally reported by Simonas Kazlauskas
<s@kazlauskas.me> in id:20130418102507.GA23688@godbox but I was only
able to reproduce and investigate now that I upgraded clang.
Previously pick had the option of using an async parser like search or
a sync parser like show. The async parser has always been the default
and it seems fine so we can remove the sync one and the corresponding
defcustom.
For my client, the largest bottleneck for displaying large threads is
exporting each html part individually since by default notmuch will not
show the json parts. For large threads there can be quite a few parts and
each must be exported and decoded one by one. Also, I then have to deal
with all the crazy charsets which I can do through a library but is a
pain.
Therefore, this patch adds an --include-html option that causes the
text/html parts to be included as part of the output of show.
diff man/man1/notmuch-show.1
notmuch-show.el and notmuch.el had 3 duplicate, identical functions:
notmuch-foreach-mime-part, notmuch-count-attachments and
notmuch-save-attachments. Now these functions in notmuch-show.el
are replaced with declare-functions pointing to "notmuch"(.el).
Add support for querying the total number of files associated with the
messages matching the search. This is mostly useful with an
id:<message-id> query for a single message.
Effective with --output=files, output the Nth filename associated with
each message matching the query (N is 1-based). If N is greater than
the number of files associated with the message, don't print anything.
notmuch-config.c has the only use of the function named "index()" in the
notmuch source. Several other places use the equivalent function
"strchr()"; this patch just fixes notmuch-config.c to use strchr()
instead. (Solaris needs to include <strings.h> to get the prototype for
index(), and notmuch-config.c was failing to include that header, so it
wasn't compiling as-is.)
This makes tab move to next button in the message pane and binds
button activate (in message pane) to "e". This means that is easy to
toggle hidden parts or hidden citations etc in the message pane.
We will want to be able to activate buttons not in the current
buffer (ie in the message pane) so it is helpful to have a way of
activating a button without signalling error if there is no button.
These functions all now work straight from their notmuch-show
implementation so link them in.
Stash functionality was one of the key missing things in notmuch-pick.
We can use the attachment functions straight from
notmuch-show. notmuch-show-view-all-mime-parts might be deprecated so
we either want to undeprecate it or not have this binding.
We override notmuch-show-get-prop so that many of the show functions
can be used in notmuch-pick without modification. The main use is that
it means notmuch-show-get-message-id `works' in pick. Thus we get all
the stash functions and several other `for free' in pick.
The timegm(3) function is a non-standard extension to libc which is
available in GNU libc and on some BSDs. Although SunOS had this
function in its libc, Solaris (unfortunately) removed it. This patch
implements a very simple version of timegm() which is good enough for
parse-time-string.c.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Solaris does not ship a version of the strsep() function. This change
adds a check to "configure" to see whether notmuch needs to provide its
own implementation, and if so, it uses the new version in
"compat/strsep.c" (which was copied from Mutt, and apparently before
that from glibc).
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Add checks to "configure" to see whether _POSIX_PTHREAD_SEMANTICS needs
to be defined to get the right number of arguments in the prototypes for
asctime_r(). Solaris' default implementation conforms to POSIX.1c
Draft 6, rather than the final POSIX.1c spec. The standards-compliant
version can be used by defining _POSIX_PTHREAD_SEMANTICS.
This change also adds the file "compat/check_asctime.c", which
configure uses to perform its check, and modifies compat/compat.h to
define _POSIX_PTHREAD_SEMANTICS if configure detected it was needed.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
Add checks to "configure" to see whether _POSIX_PTHREAD_SEMANTICS needs
to be defined to get the right number of arguments in the prototypes for
getpwuid_r(). Solaris' default implementation conforms to POSIX.1c
Draft 6, rather than the final POSIX.1c spec. The standards-compliant
version can be used by defining _POSIX_PTHREAD_SEMANTICS.
This change also adds the file "compat/check_getpwuid.c", which
configure uses to perform its check, and modifies compat/compat.h to
define _POSIX_PTHREAD_SEMANTICS if configure detected it was needed.
Signed-off-by: Vladimir Marek <vlmarek@volny.cz>
RFC 2047 states that the encoding and charset in an encoded word are
case-insensitive, so force them to lower case in the reply test. This
fixes an issue caused by GMime versions (somewhere between 2.6.10 and
2.6.16), which changed the capitalization of the encoding.
Previously, reply's default text format used an odd mix of RFC 2045
MIME encoding for the reply template's body and some made-up RFC
2822-like UTF-8 format for the headers. The intent was to present the
headers to the user in a nice, un-encoded format, but this assumed
that whatever ultimately sent the email would RFC 2047-encode the
headers, while at the same time the body was already RFC 2045 encoded,
so it assumed that whatever sent the email would *not* re-encode the
body.
This can be fixed by either producing a fully decoded UTF-8 reply
template, or a fully encoded MIME-compliant RFC 2822 message. This
patch does the latter because it is
a) Well-defined by RFC 2822 and MIME (while any UTF-8 format would be
ad hoc).
b) Ready to be piped to sendmail. The point of the text format is to
be minimal, so a user should be able to pop up the template in
whatever editor they want, edit it, and push it to sendmail.
c) Consistent with frontend capabilities. If a frontend has the
smarts to RFC 2047 encode the headers before sending the mail, it
probably has the smarts to RFC 2047 decode them before presenting
the template to a user for editing.
Also, as far as I know, nothing automated consumes the reply text
format, so changing this should not cause serious problems. (And if
anything does still consume this format, it probably gets these
encoding issues wrong anyway.)
