[PATCH] test: fix tests for content-disposition
This fixes all tests for the recent addition of content-disposition to
the structured format outputs of notmuch-show.
---
Since Jani added the content-disposition as I wanted to use it from emacs
(thanks Jani!)
I thought I should fix the tests.
I don't know if it should be folded in to the main patch or applied
separately. Either is fine with me.
Best wishes
Mark
test/T160-json.sh | 2 +-
test/T170-sexp.sh | 2 +-
test/T190-multipart.sh | 22 ++
test/T350-crypto.sh| 1 +
4 files changed, 17 insertions(+), 10 deletions(-)
diff --git a/test/T160-json.sh b/test/T160-json.sh
index b346f37..74e0d8f 100755
--- a/test/T160-json.sh
+++ b/test/T160-json.sh
@@ -48,7 +48,7 @@ output=$(notmuch show --format=json "id:$id")
filename=$(notmuch search --output=files "id:$id")
# Get length of README after base64-encoding, minus additional newline.
attachment_length=$(( $(base64 $TEST_DIRECTORY/README | wc -c) - 1 ))
-test_expect_equal_json "$output" "[[[{\"id\": \"$id\", \"match\": true,
\"excluded\": false, \"filename\": \"$filename\", \"timestamp\": 946728000,
\"date_relative\": \"2000-01-01\", \"tags\": [\"inbox\"], \"headers\":
{\"Subject\": \"$subject\", \"From\": \"Notmuch Test Suite
\", \"To\": \"test_su...@notmuchmail.org\",
\"Date\": \"Sat, 01 Jan 2000 12:00:00 +\"}, \"body\": [{\"id\": 1,
\"content-type\": \"multipart/mixed\", \"content\": [{\"id\": 2,
\"content-type\": \"text/plain\", \"content\": \"This is a test message with
inline attachment with a filename\"}, {\"id\": 3, \"content-type\":
\"application/octet-stream\", \"content-length\": $attachment_length,
\"content-transfer-encoding\": \"base64\", \"filename\": \"README\"}]}]}, ["
+test_expect_equal_json "$output" "[[[{\"id\": \"$id\", \"match\": true,
\"excluded\": false, \"filename\": \"$filename\", \"timestamp\": 946728000,
\"date_relative\": \"2000-01-01\", \"tags\": [\"inbox\"], \"headers\":
{\"Subject\": \"$subject\", \"From\": \"Notmuch Test Suite
\", \"To\": \"test_su...@notmuchmail.org\",
\"Date\": \"Sat, 01 Jan 2000 12:00:00 +\"}, \"body\": [{\"id\": 1,
\"content-type\": \"multipart/mixed\", \"content\": [{\"id\": 2,
\"content-type\": \"text/plain\", \"content\": \"This is a test message with
inline attachment with a filename\"}, {\"id\": 3, \"content-type\":
\"application/octet-stream\", \"content-length\": $attachment_length,
\"content-transfer-encoding\": \"base64\", \"content-disposition\": \"inline\",
\"filename\": \"README\"}]}]}, ["
test_begin_subtest "Search message: json, utf-8"
add_message "[subject]=\"json-search-utf8-body-sübjéct\"" "[date]=\"Sat, 01
Jan 2000 12:00:00 -\"" "[body]=\"jsön-search-méssage\""
diff --git a/test/T170-sexp.sh b/test/T170-sexp.sh
index 800ebc6..2088972 100755
--- a/test/T170-sexp.sh
+++ b/test/T170-sexp.sh
@@ -39,7 +39,7 @@ output=$(notmuch show --format=sexp "id:$id")
filename=$(notmuch search --output=files "id:$id")
# Get length of README after base64-encoding, minus additional newline.
attachment_length=$(( $(base64 $TEST_DIRECTORY/README | wc -c) - 1 ))
-test_expect_equal "$output" ":id \"$id\" :match t :excluded nil :filename
\"$filename\" :timestamp 946728000 :date_relative \"2000-01-01\" :tags
(\"inbox\") :headers (:Subject \"sexp-show-inline-attachment-filename\" :From
\"Notmuch Test Suite \" :To
\"test_su...@notmuchmail.org\" :Date \"Sat, 01 Jan 2000 12:00:00 +\") :body
((:id 1 :content-type \"multipart/mixed\" :content ((:id 2 :content-type
\"text/plain\" :content \"This is a test message with inline attachment with a
filename\") (:id 3 :content-type \"application/octet-stream\" :filename
\"README\" :content-transfer-encoding \"base64\" :content-length
$attachment_length) ("
+test_expect_equal "$output" ":id \"$id\" :match t :excluded nil :filename
\"$filename\" :timestamp 946728000 :date_relative \"2000-01-01\" :tags
(\"inbox\") :headers (:Subject \"sexp-show-inline-attachment-filename\" :From
\"Notmuch Test Suite \" :To
\"test_su...@notmuchmail.org\" :Date \"Sat, 01 Jan 2000 12:00:00 +\") :body
((:id 1 :content-type \"multipart/mixed\" :content ((:id 2 :content-type
\"text/plain\" :content \"This is a test message with inline attachment with a
filename\") (:id 3 :content-type \"application/octet-stream\"
:content-disposition \"inline\" :filename \"README\" :content-transfer-encoding
\"base64\" :content-length $attachment_length) ("
test_begin_subtest "Search message: sexp, utf-8"
add_message "[subject]=\"sexp-search-utf8-body-sübjéct\"" "[date]=\"Sat, 01
Jan 2000 12:00:00 -\"" "[body]=\"jsön-search-méssage\""
diff --git a/test/T190-multipart.sh b/test/T190-multipart.sh
index 3567890..b631c5e 100755
--- a/test/T190-multipart.sh
+++ b/test/T190-multipart.sh
@@ -348,11 +348,11 @@ cat
Re: [PATCH 2/2] cli/show: add content-disposition to structured output message parts
On Sat, 28 Jan 2017, Jani Nikula wrote:
> Help the clients decide how to display parts.
This series looks good to me. I would say +1, but I am not sure my
knowledge of C is really up to that.
There are a bunch of tests to update; I will send a patch to do that in
shortly.
> I'm not sure if this should bump the version in schemata, because the
> comment in notmuch-client.h says new map fields can be added without
> increasing NOTMUCH_FORMAT_CUR. Yet the schemata version history says
> thread_summary.query was added in v2... which looks like a change that
> shouldn't need a version bump. Confused.
I think the reason for the bump before was that the client needed to
know it had got the new format, so it could either bail out, or at least
work around it, if it got the old format.
In this case though, I think any sane program has to treat
content-disposition nil as being "do whatever the default is" (since I
don't think all parts have a content-disposition).
Thus, I don't think we need a schemata bump, as the client can just use
the extra information if present, and otherwise do what it normally would.
Best wishes
Mark
>
> The problem could be avoided by conflating both this change and
> id:20170110201929.21875-1-j...@nikula.org into v3... ;)
> ---
> devel/schemata | 1 +
> notmuch-show.c | 6 ++
> 2 files changed, 7 insertions(+)
>
> diff --git a/devel/schemata b/devel/schemata
> index 41dc4a60fff3..c94459eb783a 100644
> --- a/devel/schemata
> +++ b/devel/schemata
> @@ -76,6 +76,7 @@ part = {
> sigstatus?: sigstatus,
>
> content-type: string,
> +content-disposition?: string,
> content-id?:string,
> # if content-type starts with "multipart/":
> content:[part*],
> diff --git a/notmuch-show.c b/notmuch-show.c
> index 8b38fe6db136..8e69b3465886 100644
> --- a/notmuch-show.c
> +++ b/notmuch-show.c
> @@ -582,6 +582,7 @@ format_part_sprinter (const void *ctx, sprinter_t *sp,
> mime_node_t *node,
> GMimeObject *meta = node->envelope_part ?
> GMIME_OBJECT (node->envelope_part) : node->part;
> GMimeContentType *content_type = g_mime_object_get_content_type (meta);
> +const char *disposition = _get_disposition (meta);
> const char *cid = g_mime_object_get_content_id (meta);
> const char *filename = GMIME_IS_PART (node->part) ?
> g_mime_part_get_filename (GMIME_PART (node->part)) : NULL;
> @@ -611,6 +612,11 @@ format_part_sprinter (const void *ctx, sprinter_t *sp,
> mime_node_t *node,
> sp->map_key (sp, "content-type");
> sp->string (sp, g_mime_content_type_to_string (content_type));
>
> +if (disposition) {
> + sp->map_key (sp, "content-disposition");
> + sp->string (sp, disposition);
> +}
> +
> if (cid) {
> sp->map_key (sp, "content-id");
> sp->string (sp, cid);
> --
> 2.11.0
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v4] lib: regexp matching in 'subject' and 'from'
On Wed, 25 Jan 2017, David Bremner wrote:
> Tomi Ollila writes:
>
>>
>> Why would not mesasge_id not be useful to regex match. I can come up quite
>> a few use cases... but if there are techinal difficulties... then that
>> should be mentioned instead.
>
> I'll have a look. Since the first version of this patch (when that
> message was written), people have actually asked for some kind of
> wildcard matching of message-ids.
Theoretically "/" is an acceptable character in message-ids [1]. Rare,
unlikely, but acceptable. Searching for message-id's beginning with "/"
would have to use regexps, which would break in all sorts of ways
throughout the stack. I don't think there are handy alternatives to
"//", given the characters that are acceptable in message-ids,
but this is something to think about.
For example, could the regexp matcher for message-ids first check if the
"regexp" is a strict match with "/" and all, and accept those? This
might be a reasonable workaround if it can be made to work.
[1] https://tools.ietf.org/html/rfc2822#section-3.2.4
>> maybe this commit message should inform that xapian with field processors
>> (1.4.x) is required for this feature -- and emphasize it a bit better in
>> manual page ?
>>
>> Probably '//' is used to escape '/' -- should such a character ever needed
>> in regex search.
>>
>
> Currently no escaping is needed because it only looks at the first and
> last characters of the string (the usual xapian/shell rules mean that "" might
> be needed).
>
> The following seem to work as hoped
>
> # match a / with a space before it
>
> % notmuch search 'subject:"/ //"'
>
> # just a slash
>
> % notmuch search subject:///
>
> # anchored slash
>
> % notmuch search subject:/^//
>
> The trailing slash is actually decorative, we could drop it. Actually
> *blush* I just noticed the current code is missing something from this line
>
> if (str.at (0) == '/' && str.at (str.size () - 1)){
>
> _if_ that line is fixed, then it will have the slightly odd behaviour of
>
> subject:/blah
>
> doing a non-regex search
>
> We could also throw an error for that case, maybe that's the best option.
I'd go with an error. It's easy to loosen the rules later on if we
decide that's a good idea. Much harder to accept loose rules now, let
users get used to it, and try to tighten the rules if we realize we'd
need that for some reason.
BR,
Jani.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [Patch v4] lib: regexp matching in 'subject' and 'from'
On Wed, 25 Jan 2017, Tomi Ollila wrote: > On Sat, Jan 21 2017, David Bremner wrote: > >> the idea is that you can run >> >> % notmuch search subject:// >> % notmuch search from:// > > I like this interface. FWIW I think this is superior to the earlier alternatives too. I think people would like to use regexps (or globbing) for path: and folder: queries. Is there a risk of ambiguity between normal path: and folder: searches and regexp searches due to "/"? I suppose the normal queries never begin with "/" for them (due to being relative to database path, not absolute) but is that confusing? BR, Jani. > >> >> or >> >> % notmuch search subject:"your usual phrase search" >> % notmuch search from:"usual phrase search" >> >> This should also work with bindings, since it extends the query parser. >> >> This is trivial to extend for other value slots, but currently the only >> value slots are date, message_id, from, subject, and last_mod. Date is >> already searchable, and message_id is not obviously useful to regex >> match. > > Why would not mesasge_id not be useful to regex match. I can come up quite > a few use cases... but if there are techinal difficulties... then that > should be mentioned instead. > > maybe this commit message should inform that xapian with field processors > (1.4.x) is required for this feature -- and emphasize it a bit better in > manual page ? > > Probably '//' is used to escape '/' -- should such a character ever needed > in regex search. > >> >> This was originally written by Austin Clements, and ported to Xapian >> field processors (from Austin's custom query parser) by yours truly. >> --- >> >> This version impliments the use of // to delimit regular expressions. >> I have not tested the code paths with old (pre field processor) xapian. > > Fedora 25 has 1.2.24 -- T630 tests are skipped. It looks like these changes > did not increase the failure count there. > > Some (mostly whitespace nitpicking) comments below: > > >> >> doc/man7/notmuch-search-terms.rst | 27 +++- >> lib/Makefile.local| 1 + >> lib/database-private.h| 2 + >> lib/database.cc | 29 +++- >> lib/regexp-fields.cc | 142 >> ++ >> lib/regexp-fields.h | 77 + >> test/T630-regexp-query.sh | 82 ++ >> 7 files changed, 354 insertions(+), 6 deletions(-) >> create mode 100644 lib/regexp-fields.cc >> create mode 100644 lib/regexp-fields.h >> create mode 100755 test/T630-regexp-query.sh >> >> diff --git a/doc/man7/notmuch-search-terms.rst >> b/doc/man7/notmuch-search-terms.rst >> index de93d733..d8527e18 100644 >> --- a/doc/man7/notmuch-search-terms.rst >> +++ b/doc/man7/notmuch-search-terms.rst >> @@ -34,10 +34,14 @@ indicate user-supplied values): >> >> - from: >> >> +- from:// >> + >> - to: >> >> - subject: >> >> +- subject:// >> + >> - attachment: >> >> - mimetype: >> @@ -71,6 +75,17 @@ subject of an email. Searching for a phrase in the >> subject is supported >> by including quotation marks around the phrase, immediately following >> **subject:**. >> >> +The **from:** and **subject** prefix can be also used to restrict the >> +results to those whose from/subject value matches a regular >> +expression (see **regex(7)**) delimited with //. >> + >> +:: >> + >> + notmuch search 'from:/bob@.*[.]example[.]com/' >> + >> +Regular expression searches are only available if notmuch is built >> +with **Xapian Field Processors** (see below). > > And the poor user stopped reading far before this line, desperately trying > the regex searches... >;/ so IMO this requirement should be notified earlier. > >> + >> The **attachment:** prefix can be used to search for specific filenames >> (or extensions) of attachments to email messages. >> >> @@ -220,13 +235,18 @@ Boolean and Probabilistic Prefixes >> -- >> >> Xapian (and hence notmuch) prefixes are either **boolean**, supporting >> -exact matches like "tag:inbox" or **probabilistic**, supporting a more >> flexible **term** based searching. The prefixes currently supported by >> notmuch are as follows. >> - >> +exact matches like "tag:inbox" or **probabilistic**, supporting a more >> +flexible **term** based searching. Certain **special** prefixes are >> +processed by notmuch in a way not stricly fitting either of Xapian's >> +built in styles. The prefixes currently supported by notmuch are as >> +follows. >> >> Boolean >> **tag:**, **id:**, **thread:**, **folder:**, **path:**, **property:** >> Probabilistic >> - **from:**, **to:**, **subject:**, **attachment:**, **mimetype:** >> + **to:**, **attachment:**, **mimetype:** >> +Special >> + **from:**, **query:**, **subject:** >> >> Terms and phrases >> - >> @@ -396,6 +416,7 @@ Currently the following features require field processor >> support: >> >> - non
Re: [RFC Patch 2/2] lib: Let Xapian manage the memory for FieldProcessors
On Sat, 28 Jan 2017, David Bremner wrote:
> It turns out this is exactly what release() is for; Xapian will
> deallocate the objects when it's done with them.
release() fares 2 on Rusty scale [1][2]... after digging through source,
LGTM.
BR,
Jani.
[1] http://ozlabs.org/~rusty/index.cgi/tech/2008-03-30.html
[2] http://ozlabs.org/~rusty/index.cgi/tech/2008-04-01.html
> ---
> lib/database-private.h | 4
> lib/database.cc| 19 ---
> 2 files changed, 8 insertions(+), 15 deletions(-)
>
> diff --git a/lib/database-private.h b/lib/database-private.h
> index 32357ce0..3eac3c7e 100644
> --- a/lib/database-private.h
> +++ b/lib/database-private.h
> @@ -194,10 +194,6 @@ struct _notmuch_database {
> Xapian::TermGenerator *term_gen;
> Xapian::ValueRangeProcessor *value_range_processor;
> Xapian::ValueRangeProcessor *date_range_processor;
> -#if HAVE_XAPIAN_FIELD_PROCESSOR
> -Xapian::FieldProcessor *date_field_processor;
> -Xapian::FieldProcessor *query_field_processor;
> -#endif
> Xapian::ValueRangeProcessor *last_mod_range_processor;
> };
>
> diff --git a/lib/database.cc b/lib/database.cc
> index b98468a6..c1563ca7 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1029,10 +1029,14 @@ notmuch_database_open_verbose (const char *path,
> #if HAVE_XAPIAN_FIELD_PROCESSOR
> /* This currently relies on the query parser to pass anything
>* with a .. to the range processor */
> - notmuch->date_field_processor = new DateFieldProcessor();
> - notmuch->query_parser->add_boolean_prefix("date",
> notmuch->date_field_processor);
> - notmuch->query_field_processor = new QueryFieldProcessor
> (*notmuch->query_parser, notmuch);
> - notmuch->query_parser->add_boolean_prefix("query",
> notmuch->query_field_processor);
> + {
> + Xapian::FieldProcessor * date_fp = new DateFieldProcessor();
> + Xapian::FieldProcessor * query_fp =
> + new QueryFieldProcessor (*notmuch->query_parser, notmuch);
> +
> + notmuch->query_parser->add_boolean_prefix("date", date_fp->release
> ());
> + notmuch->query_parser->add_boolean_prefix("query",
> query_fp->release ());
> + }
> #endif
> notmuch->last_mod_range_processor = new
> Xapian::NumberValueRangeProcessor (NOTMUCH_VALUE_LAST_MOD, "lastmod:");
>
> @@ -1125,13 +1129,6 @@ notmuch_database_close (notmuch_database_t *notmuch)
> delete notmuch->last_mod_range_processor;
> notmuch->last_mod_range_processor = NULL;
>
> -#if HAVE_XAPIAN_FIELD_PROCESSOR
> -delete notmuch->date_field_processor;
> -notmuch->date_field_processor = NULL;
> -delete notmuch->query_field_processor;
> -notmuch->query_field_processor = NULL;
> -#endif
> -
> return status;
> }
>
> --
> 2.11.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Re: [RFC Patch 1/2] lib: merge internal prefix tables
On Sat, 28 Jan 2017, David Bremner wrote:
> Replace multiple tables with some flags in a single table. This makes
> the code a bit shorter, and it should also make it easier to add
> other options to fields, e.g. regexp searching.
> ---
> lib/database-private.h | 7
> lib/database.cc| 86
> +++---
> 2 files changed, 46 insertions(+), 47 deletions(-)
>
> diff --git a/lib/database-private.h b/lib/database-private.h
> index ccc1e9a1..32357ce0 100644
> --- a/lib/database-private.h
> +++ b/lib/database-private.h
> @@ -148,6 +148,13 @@ operator&=(_notmuch_features &a, _notmuch_features b)
> return a;
> }
>
> +/*
> + * Configuration options for xapian database fields */
> +typedef enum notmuch_field_flags {
> +NOTMUCH_FIELD_EXTERNAL = 1,
> +NOTMUCH_FIELD_PROBABILISTIC = 2
Since these are used as bit flags, I think it would more clear if they
were defined as (1 << 0) and (1 << 1).
I'm not sure if the enum buys us anything over defining them as macros,
but I could go either way.
> +} notmuch_field_flag_t;
> +
> #define NOTMUCH_QUERY_PARSER_FLAGS (Xapian::QueryParser::FLAG_BOOLEAN | \
> Xapian::QueryParser::FLAG_PHRASE | \
> Xapian::QueryParser::FLAG_LOVEHATE | \
> diff --git a/lib/database.cc b/lib/database.cc
> index 2d19f20c..b98468a6 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -42,6 +42,7 @@ using namespace std;
> typedef struct {
> const char *name;
> const char *prefix;
> +int flags;
> } prefix_t;
>
> #define NOTMUCH_DATABASE_VERSION 3
> @@ -247,37 +248,37 @@ typedef struct {
> * nearly universal to all mail messages).
> */
>
> -static prefix_t BOOLEAN_PREFIX_INTERNAL[] = {
> -{ "type","T" },
> -{ "reference", "XREFERENCE" },
> -{ "replyto", "XREPLYTO" },
> -{ "directory", "XDIRECTORY" },
> -{ "file-direntry", "XFDIRENTRY" },
> -{ "directory-direntry", "XDDIRENTRY" },
> -};
> -
> -static prefix_t BOOLEAN_PREFIX_EXTERNAL[] = {
> -{ "thread", "G" },
> -{ "tag", "K" },
> -{ "is", "K" },
> -{ "id", "Q" },
> -{ "path","P" },
> -{ "property","XPROPERTY" },
> +static prefix_t PREFIX[] = {
Not really specific to this patch, but while at it this could be made
const, and perhaps renamed lower case. The upper case names always
seemed a bit odd. Can be left for follow-up too.
Otherwise, LGTM, a nice cleanup.
BR,
Jani.
> +/* name term prefix flags */
> +{ "type","T",0 },
> +{ "reference", "XREFERENCE", 0 },
> +{ "replyto", "XREPLYTO", 0 },
> +{ "directory", "XDIRECTORY", 0 },
> +{ "file-direntry", "XFDIRENTRY", 0 },
> +{ "directory-direntry", "XDDIRENTRY", 0 },
> +{ "thread", "G",NOTMUCH_FIELD_EXTERNAL
> },
> +{ "tag", "K",NOTMUCH_FIELD_EXTERNAL },
> +{ "is", "K",NOTMUCH_FIELD_EXTERNAL },
> +{ "id", "Q",NOTMUCH_FIELD_EXTERNAL },
> +{ "path","P",NOTMUCH_FIELD_EXTERNAL
> },
> +{ "property","XPROPERTY",NOTMUCH_FIELD_EXTERNAL },
> /*
> * Unconditionally add ':' to reduce potential ambiguity with
> * overlapping prefixes and/or terms that start with capital
> * letters. See Xapian document termprefixes.html for related
> * discussion.
> */
> -{ "folder", "XFOLDER:" },
> -};
> -
> -static prefix_t PROBABILISTIC_PREFIX[]= {
> -{ "from","XFROM" },
> -{ "to", "XTO" },
> -{ "attachment", "XATTACHMENT" },
> -{ "mimetype","XMIMETYPE"},
> -{ "subject", "XSUBJECT"},
> +{ "folder", "XFOLDER:", NOTMUCH_FIELD_EXTERNAL
> },
> +{ "from","XFROM",NOTMUCH_FIELD_EXTERNAL |
> + NOTMUCH_FIELD_PROBABILISTIC },
> +{ "to", "XTO", NOTMUCH_FIELD_EXTERNAL |
> + NOTMUCH_FIELD_PROBABILISTIC },
> +{ "attachment", "XATTACHMENT", NOTMUCH_FIELD_EXTERNAL |
> + NOTMUCH_FIELD_PROBABILISTIC },
> +{ "mimetype","XMIMETYPE",NOTMUCH_FIELD_EXTERNAL |
> + NOTMUCH_FIELD_PROBABILISTIC },
> +{ "subject", "XSUBJECT", NOTMUCH_FIELD_EXTERNAL |
> + NOTMUCH_FIELD_PROBABILISTIC },
> };
>
> const char *
> @@ -285,1
[PATCH 0/2] emacs: Fold long headers when sending
This pair of patches add a test for folding long headers, and backport the bugfix from emacs master. This fixes the bug reported in id:87612qwh04@viking.dsc.soic.indiana.edu The fix in emacs master (77bbca8c82f6e553c42abbfafca28f55fc995d00) runs the folding function just before message-header-hook, so this fix should give almost exactly the same behaviour. Since message--fold-long-headers was introduced in the same commit this should mean we do not apply the fix for any version of emacs which it already has it. I don't know whether my bash in the test suite is sufficiently portable, so if anyone who knows about that could check I would be grateful. (For example, is seq -s " " 1 1000 standard?) Best wishes Mark Mark Walters (2): Test: emacs: test for folding long headers. emacs: compat: backport fix for folding long headers when sending emacs/notmuch-compat.el | 28 +++--- test/T310-emacs.sh | 78 + 2 files changed, 102 insertions(+), 4 deletions(-) -- 2.1.4 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
[PATCH 1/2] Test: emacs: test for folding long headers.
Headers of more than 998 characters should be folded when sending.
However, until recently, emacs did not do this.
This adds a (known broken) test for this when sending messages in
emacs. We will backport the fix to notmuch-emacs in the next
changeset.
---
test/T310-emacs.sh | 79 ++
1 file changed, 79 insertions(+)
diff --git a/test/T310-emacs.sh b/test/T310-emacs.sh
index 01385ae..5331514 100755
--- a/test/T310-emacs.sh
+++ b/test/T310-emacs.sh
@@ -208,6 +208,85 @@ This is a test that messages are sent via SMTP
EOF
test_expect_equal_file OUTPUT EXPECTED
+test_begin_subtest "Folding a long header when sending via (fake) SMTP"
+test_subtest_known_broken
+long_subject="This is a long subject `seq -s ' ' 1 1000`"
+emacs_deliver_message \
+"${long_subject}" \
+'This is a test that long headers are folded when messages are sent via
SMTP' \
+'(message-goto-to)
+ (kill-whole-line)
+ (insert "To: u...@example.com\n")'
+sed \
+-e s',^Message-ID: <.*>$,Message-ID: ,' \
+-e s',^\(Content-Type: text/plain\); charset=us-ascii$,\1,' < sent_message
>OUTPUT
+cat
[PATCH 2/2] emacs: compat: backport fix for folding long headers when sending
This backports the fix from emacs master (commit
77bbca8c82f6e553c42abbfafca28f55fc995d00) to notmuch-emacs to wrap
long headers.
This fixes the test introduced in the previous changeset.
---
emacs/notmuch-compat.el | 28
test/T310-emacs.sh | 1 -
2 files changed, 24 insertions(+), 5 deletions(-)
diff --git a/emacs/notmuch-compat.el b/emacs/notmuch-compat.el
index c3d827a..e71e861 100644
--- a/emacs/notmuch-compat.el
+++ b/emacs/notmuch-compat.el
@@ -1,8 +1,28 @@
-;; Compatibility functions for emacs 23 and 24 pre 24.4
+;; Compatibility functions for earlier versions of emacs
-;; The functions in this file are copied from eamcs 24.4 and are
-;; Copyright (C) 1985-1986, 1992, 1994-1995, 1999-2014 Free Software
-;; Foundation, Inc.
+;; The functions in this file are copied from more modern versions of
+;; emacs and are Copyright (C) 1985-1986, 1992, 1994-1995, 1999-2017
+;; Free Software Foundation, Inc.
+
+
+
+;; emacs master has a bugfix for folding long headers when sending
+;; messages. Include the fix for earlier versions of emacs. To avoid
+;; interfering with gnus we only run the hook when called from
+;; notmuch-message-mode.
+
+(declare-function mail-header-fold-field "mail-parse" nil)
+
+(unless (fboundp 'message--fold-long-headers)
+ (add-hook 'message-header-hook
+ (lambda ()
+ (when (eq major-mode 'notmuch-message-mode)
+ (goto-char (point-min))
+ (while (not (eobp))
+ (when (and (looking-at "[^:]+:")
+(> (- (line-end-position) (point)) 998))
+ (mail-header-fold-field))
+ (forward-line 1))
(if (fboundp 'setq-local)
(defalias 'notmuch-setq-local 'setq-local)
diff --git a/test/T310-emacs.sh b/test/T310-emacs.sh
index 5331514..a486df8 100755
--- a/test/T310-emacs.sh
+++ b/test/T310-emacs.sh
@@ -209,7 +209,6 @@ EOF
test_expect_equal_file OUTPUT EXPECTED
test_begin_subtest "Folding a long header when sending via (fake) SMTP"
-test_subtest_known_broken
long_subject="This is a long subject `seq -s ' ' 1 1000`"
emacs_deliver_message \
"${long_subject}" \
--
2.1.4
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
