[PATCH] configure: Fix syntax error (spaces in assignment).
Before and after the assignment operator, no spaces are allowed. I don't know if there are any /bin/sh which allow spaces, but at least in bash, csh and zsh, the former code was no valid assigment. --- configure |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index eebe075..7f5ca7d 100755 --- a/configure +++ b/configure @@ -238,11 +238,11 @@ printf "Checking for Mac OS X (for shared library)... " if [ `uname` = "Darwin" ] ; then printf "Yes.\n" mac_os_x=1 -linker_resolves_library_dependencies = 0 +linker_resolves_library_dependencies=0 else printf "No.\n" mac_os_x=0 -linker_resolves_library_dependencies = 1 +linker_resolves_library_dependencies=1 fi if [ $errors -gt 0 ]; then -- 1.7.0.4
[PATCH] configure: Fix syntax error (spaces in assignment).
Before and after the assignment operator, no spaces are allowed. I don't know if there are any /bin/sh which allow spaces, but at least in bash, csh and zsh, the former code was no valid assigment. --- configure |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/configure b/configure index eebe075..7f5ca7d 100755 --- a/configure +++ b/configure @@ -238,11 +238,11 @@ printf Checking for Mac OS X (for shared library)... if [ `uname` = Darwin ] ; then printf Yes.\n mac_os_x=1 -linker_resolves_library_dependencies = 0 +linker_resolves_library_dependencies=0 else printf No.\n mac_os_x=0 -linker_resolves_library_dependencies = 1 +linker_resolves_library_dependencies=1 fi if [ $errors -gt 0 ]; then -- 1.7.0.4 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] First tests for JSON output and UTF-8 in mail body and subject
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search --format=json' and
'show --format=json'.
Furthermore, it has test cases for a search for a UTF-8 string in a mail
body for a UTF-8 string in a mail subject.
Finally, it has a test case for --format=json with UTF-8 messages,
demonstrating the fix in 1267697893-sup-4538 at sam.mediasupervision.de.
---
test/notmuch-test | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/test/notmuch-test b/test/notmuch-test
index 1c5191b..b2a0756 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -146,7 +146,7 @@ add_message ()
}
NOTMUCH_IGNORED_OUTPUT_REGEXP='^Processed [0-9]*( total)? file|Found [0-9]*
total file'
-NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'
+NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/;s/"thread":
"",/"thread": "XXX",/'
execute_expecting ()
{
args=$1
@@ -348,6 +348,42 @@ add_message '[subject]="body search (phrase)"'
'[date]="Sat, 01 Jan 2000 12:00:0
add_message '[subject]="negative result"' '[date]="Sat, 01 Jan 2000 12:00:00
-"' '[body]="This phrase should not match the body search"'
execute_expecting "search '\"body search (phrase)\"'" "thread:XXX 2000-01-01
[1/1] Notmuch Test Suite; body search (phrase) (inbox unread)"
+printf " Show message: json...\t\t"
+add_message '[subject]="json-show-subject"' '[date]="Sat, 01 Jan 2000 12:00:00
-"' '[body]="json-show-message"'
+execute_expecting "show --format=json 'json-show-message'" '[[[{"id":
"'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'",
"date_unix": 946728000, "date_relative": "2000-01-01", "tags":
["inbox","unread"], "headers": {"Subject": "json-show-subject", "From":
"Notmuch Test Suite ", "To": "Notmuch Test Suite
", "Cc": "", "Bcc": "", "Date": "Sat, 01 Jan
2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain",
"content": "json-show-message\n"}]}, ['
+
+printf " Search message: json...\t"
+add_message '[subject]="json-search-subject"' '[date]="Sat, 01 Jan 2000
12:00:00 -"' '[body]="json-search-message"'
+execute_expecting "search --format=json 'json-search-message'" '[{"thread":
"XXX",
+"timestamp": 946724400,
+"matched": 1,
+"total": 1,
+"authors": "Notmuch Test Suite",
+"subject": "json-search-subject",
+"tags": ["inbox", "unread"]}]'
+
+printf " Search by subject (utf-8):...\t"
+add_message [subject]=utf8-s?bj?ct '[date]="Sat, 01 Jan 2000 12:00:00 -"'
+execute_expecting "search subject:utf8-s?bj?ct" "thread:XXX 2000-01-01 [1/1]
Notmuch Test Suite; utf8-s?bj?ct (inbox unread)"
+
+printf " Search body (utf-8):...\t"
+add_message '[subject]="utf8-message-body-subject"' '[date]="Sat, 01 Jan 2000
12:00:00 -"' '[body]="message body utf8: b?d?"'
+execute_expecting "search 'b?d?'" "thread:XXX 2000-01-01 [1/1] Notmuch Test
Suite; utf8-message-body-subject (inbox unread)"
+
+printf " Show message: json, utf-8...\t"
+add_message '[subject]="json-show-utf8-body-s?bj?ct"' '[date]="Sat, 01 Jan
2000 12:00:00 -"' '[body]="js?n-show-m?ssage"'
+execute_expecting "show --format=json 'js?n-show-m?ssage'" '[[[{"id":
"'${gen_msg_id}'", "match": true, "filename": "'${gen_msg_filename}'",
"date_unix": 946728000, "date_relative": "2000-01-01", "tags":
["inbox","unread"], "headers": {"Subject": "json-show-utf8-body-s?bj?ct",
"From": "Notmuch Test Suite ", "To": "Notmuch
Test Suite ", "Cc": "", "Bcc": "", "Date": "Sat,
01 Jan 2000 12:00:00 -"}, "body": [{"id": 1, "content-type": "text/plain",
"content": "js?n-show-m?ssage\n"}]}, ['
+
+printf " Search message: json, utf-8...\t"
+add_message '[subject]="json-search-utf8-body-s?bj?ct"' '[date]="Sat, 01 Jan
2000 12:00:00 -"' '[body]="js?n-search-m?ssage"'
+execute_expecting "search --format=json 'js?n-search-m?ssage'" '[{"thread":
"XXX",
+"timestamp": 946724400,
+"matched": 1,
+"total": 1,
+"authors": "Notmuch Test Suite",
+"subject": "json-search-utf8-body-s?bj?ct",
+"tags": ["inbox", "unread"]}]'
+
printf " Search by from: (address)...\t"
add_message '[subject]="search by from (address)"' '[date]="Sat, 01 Jan 2000
12:00:00 -"' [from]=searchbyfrom at example.com
execute_expecting "search from:searchbyfrom at example.com" "thread:XXX
2000-01-01 [1/1] searchbyfrom at example.com; search by from (address) (inbox
unread)"
[PATCH] First tests for JSON output and UTF-8 in mail body and subject
The test suite doesn't yet cover --format=json output nor UTF-8 in
subject or body.
This patch starts with test cases for 'search --format=json' and
'show --format=json'.
Furthermore, it has test cases for a search for a UTF-8 string in a mail
body for a UTF-8 string in a mail subject.
Finally, it has a test case for --format=json with UTF-8 messages,
demonstrating the fix in 1267697893-sup-4...@sam.mediasupervision.de.
---
test/notmuch-test | 38 ++
1 files changed, 38 insertions(+), 0 deletions(-)
diff --git a/test/notmuch-test b/test/notmuch-test
index 1c5191b..b2a0756 100755
--- a/test/notmuch-test
+++ b/test/notmuch-test
@@ -146,7 +146,7 @@ add_message ()
}
NOTMUCH_IGNORED_OUTPUT_REGEXP='^Processed [0-9]*( total)? file|Found [0-9]*
total file'
-NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/'
+NOTMUCH_THREAD_ID_SQUELCH='s/thread:/thread:XXX/;s/thread:
,/thread: XXX,/'
execute_expecting ()
{
args=$1
@@ -348,6 +348,42 @@ add_message '[subject]=body search (phrase)'
'[date]=Sat, 01 Jan 2000 12:00:0
add_message '[subject]=negative result' '[date]=Sat, 01 Jan 2000 12:00:00
-' '[body]=This phrase should not match the body search'
execute_expecting search '\body search (phrase)\' thread:XXX 2000-01-01
[1/1] Notmuch Test Suite; body search (phrase) (inbox unread)
+printf Show message: json...\t\t
+add_message '[subject]=json-show-subject' '[date]=Sat, 01 Jan 2000 12:00:00
-' '[body]=json-show-message'
+execute_expecting show --format=json 'json-show-message' '[[[{id:
'${gen_msg_id}', match: true, filename: '${gen_msg_filename}',
date_unix: 946728000, date_relative: 2000-01-01, tags:
[inbox,unread], headers: {Subject: json-show-subject, From:
Notmuch Test Suite test_su...@notmuchmail.org, To: Notmuch Test Suite
test_su...@notmuchmail.org, Cc: , Bcc: , Date: Sat, 01 Jan 2000
12:00:00 -}, body: [{id: 1, content-type: text/plain, content:
json-show-message\n}]}, ['
+
+printf Search message: json...\t
+add_message '[subject]=json-search-subject' '[date]=Sat, 01 Jan 2000
12:00:00 -' '[body]=json-search-message'
+execute_expecting search --format=json 'json-search-message' '[{thread:
XXX,
+timestamp: 946724400,
+matched: 1,
+total: 1,
+authors: Notmuch Test Suite,
+subject: json-search-subject,
+tags: [inbox, unread]}]'
+
+printf Search by subject (utf-8):...\t
+add_message [subject]=utf8-sübjéct '[date]=Sat, 01 Jan 2000 12:00:00 -'
+execute_expecting search subject:utf8-sübjéct thread:XXX 2000-01-01 [1/1]
Notmuch Test Suite; utf8-sübjéct (inbox unread)
+
+printf Search body (utf-8):...\t
+add_message '[subject]=utf8-message-body-subject' '[date]=Sat, 01 Jan 2000
12:00:00 -' '[body]=message body utf8: bödý'
+execute_expecting search 'bödý' thread:XXX 2000-01-01 [1/1] Notmuch Test
Suite; utf8-message-body-subject (inbox unread)
+
+printf Show message: json, utf-8...\t
+add_message '[subject]=json-show-utf8-body-sübjéct' '[date]=Sat, 01 Jan
2000 12:00:00 -' '[body]=jsön-show-méssage'
+execute_expecting show --format=json 'jsön-show-méssage' '[[[{id:
'${gen_msg_id}', match: true, filename: '${gen_msg_filename}',
date_unix: 946728000, date_relative: 2000-01-01, tags:
[inbox,unread], headers: {Subject: json-show-utf8-body-sübjéct,
From: Notmuch Test Suite test_su...@notmuchmail.org, To: Notmuch Test
Suite test_su...@notmuchmail.org, Cc: , Bcc: , Date: Sat, 01 Jan
2000 12:00:00 -}, body: [{id: 1, content-type: text/plain,
content: jsön-show-méssage\n}]}, ['
+
+printf Search message: json, utf-8...\t
+add_message '[subject]=json-search-utf8-body-sübjéct' '[date]=Sat, 01 Jan
2000 12:00:00 -' '[body]=jsön-search-méssage'
+execute_expecting search --format=json 'jsön-search-méssage' '[{thread:
XXX,
+timestamp: 946724400,
+matched: 1,
+total: 1,
+authors: Notmuch Test Suite,
+subject: json-search-utf8-body-sübjéct,
+tags: [inbox, unread]}]'
+
printf Search by from: (address)...\t
add_message '[subject]=search by from (address)' '[date]=Sat, 01 Jan 2000
12:00:00 -' [from]=searchbyf...@example.com
execute_expecting search from:searchbyf...@example.com thread:XXX
2000-01-01 [1/1] searchbyf...@example.com; search by from (address) (inbox
unread)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
Both of you Davids are indeed completely right. Even more since the next command in the patch after memcpy zeroes that byte. This is how it's meant to be: +content_data = talloc_size (ctx, part_content->len+1); +memcpy (content_data, (char *)part_content->data, part_content->len); +content_data[part_content->len] = 0; Should I submit a fixed patch? Mea culpa, Gregor * David Edmondson [Do Apr 01 13:50:54 +0200 2010] > On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner > wrote: > > On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit > > wrote: > > > In format_part_json, part_content->data is not a null terminated > > > string. > > > > I'd like to see this bug fixed, > > +1. > > > and the patch is pretty small, but... > > > > > Instead, we have to use part_content->len. > > > +content_data = talloc_size (ctx, part_content->len+1); > > > +memcpy (content_data, (char *)part_content->data, > > > part_content->len+1); > > > > Can anyone explain why we copy (what seems to me to be) one extra byte > > here? In principle reading outside our allocated memory could cause > > problems; at minimum it makes a false positive for a memory checker like > > valgrind. > > Agreed. It looks as though this should copy only part_content->len bytes. > > dme. -- Gregor Hoffleit Media Supervision Software Consulting GmbH Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg Tel: +49 6221 705079-22 / Fax: +49 6221 705079-80 Amtsgericht Mannheim, HRB 336821, Gesch?ftsf?hrer Reinhard Kratzke http://www.mediasupervision.de/
Re: [notmuch] [PATCH] format_part_json: part_content-data is not null terminated
Both of you Davids are indeed completely right. Even more since the next command in the patch after memcpy zeroes that byte. This is how it's meant to be: +content_data = talloc_size (ctx, part_content-len+1); +memcpy (content_data, (char *)part_content-data, part_content-len); +content_data[part_content-len] = 0; Should I submit a fixed patch? Mea culpa, Gregor * David Edmondson d...@dme.org [Do Apr 01 13:50:54 +0200 2010] On Thu, 01 Apr 2010 08:40:37 -0300, David Bremner da...@tethera.net wrote: On Thu, 04 Mar 2010 11:49:48 +0100, Gregor Hoffleit gre...@hoffleit.de wrote: In format_part_json, part_content-data is not a null terminated string. I'd like to see this bug fixed, +1. and the patch is pretty small, but... Instead, we have to use part_content-len. +content_data = talloc_size (ctx, part_content-len+1); +memcpy (content_data, (char *)part_content-data, part_content-len+1); Can anyone explain why we copy (what seems to me to be) one extra byte here? In principle reading outside our allocated memory could cause problems; at minimum it makes a false positive for a memory checker like valgrind. Agreed. It looks as though this should copy only part_content-len bytes. dme. -- Gregor Hoffleit gregor.hoffl...@mediasupervision.de Media Supervision Software Consulting GmbH Georg-Friedrich-Haendel-Str. 13, 69214 Eppelheim/Heidelberg Tel: +49 6221 705079-22 / Fax: +49 6221 705079-80 Amtsgericht Mannheim, HRB 336821, Geschäftsführer Reinhard Kratzke http://www.mediasupervision.de/ ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] [PATCH] json_quote_str should handle non-ASCII characters
* Sebastian Spaeth [Do M?r 04 14:57:27 +0100 2010] > On 2010-03-04, Sebastian Spaeth wrote: > > The current code in json_quote_str() only accepts strict printable ASCII > > code points (i.e. 32-127), all other code points are dropped from the > > JSON output. > > That would explain why my web interface does not display any umlaut > symbols. Well, I noticed noneatall umlauts. That's how I found this problem. Regards, Gregor
[notmuch] [PATCH] format_part_json: part_content->data is not null terminated
In format_part_json, part_content->data is not a null terminated string.
Instead, we have to use part_content->len.
---
notmuch-show.c |7 ++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/notmuch-show.c b/notmuch-show.c
index 1a1d601..4b755e9 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -309,10 +309,15 @@ format_part_json (GMimeObject *part, int *part_count)
if (g_mime_content_type_is_type (content_type, "text", "*") &&
!g_mime_content_type_is_type (content_type, "text", "html"))
{
+ char *content_data;
+
show_part_content (part, stream_memory);
part_content = g_mime_stream_mem_get_byte_array (GMIME_STREAM_MEM
(stream_memory));
- printf (", \"content\": %s", json_quote_str (ctx, (char *)
part_content->data));
+ content_data = talloc_size (ctx, part_content->len+1);
+ memcpy (content_data, (char *)part_content->data, part_content->len+1);
+ content_data[part_content->len] = 0;
+ printf (", \"content\": %s", json_quote_str (ctx, content_data));
}
fputs ("}", stdout);
--
1.7.0
[notmuch] [PATCH] json_quote_str should handle non-ASCII characters
The current code in json_quote_str() only accepts strict printable ASCII
code points (i.e. 32-127), all other code points are dropped from the
JSON output.
This patch accepts code points 32-255.
json_quote_str() should handle non-ASCII characters.
---
json.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/json.c b/json.c
index 9614143..6dc0345 100644
--- a/json.c
+++ b/json.c
@@ -59,7 +59,7 @@ json_quote_str(const void *ctx, const char *str)
return NULL;
for (ptr = str; *ptr; len++, ptr++) {
- if (*ptr < 32 || *ptr == '\"' || *ptr == '\\')
+ if ((unsigned char)(*ptr) < 32 || *ptr == '\"' || *ptr == '\\')
len++;
}
@@ -70,7 +70,7 @@ json_quote_str(const void *ctx, const char *str)
*ptr2++ = '\"';
while (*ptr) {
- if (*ptr > 31 && *ptr != '\"' && *ptr != '\\') {
+ if ((unsigned char)(*ptr) > 31 && *ptr != '\"' && *ptr != '\\') {
*ptr2++ = *ptr++;
} else {
*ptr2++ = '\\';
--
1.7.0
Re: [notmuch] [PATCH] json_quote_str should handle non-ASCII characters
* Sebastian Spaeth sebast...@sspaeth.de [Do Mär 04 14:57:27 +0100 2010] On 2010-03-04, Sebastian Spaeth wrote: The current code in json_quote_str() only accepts strict printable ASCII code points (i.e. 32-127), all other code points are dropped from the JSON output. That would explain why my web interface does not display any umlaut symbols. Well, I noticed noneatall umlauts. That's how I found this problem. Regards, Gregor ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[notmuch] Notmuch's search view sucks
Hi there, first a short introduction: I was a mutt user for ages. When I read about Sup, I was intrigued. After a short evaluation period, I switched to Sup, which I'm now using since six months. Sup has many rough edges on its own, and it's not that easy to fix some of them from the current codebase. notmuch looks like a clean restart of the same idea, but with a different architecture. I like the concept of a command line tool with a minimal set of functionality as a common core, upon which different clients can build on. But. Compared to Sup, the current notmuch clients suck :-) Today: Sup's search-results-mode. It has a lot of polish that's plainly missing from notmuch.el (or notmuch.vim): - Sup's display is much terse than notmuch, still - Sup manages to display the first few words of the first unread message in the thread. - If a thread contains many authors, Sup shows only the firstnames. If that's still too long to fit, it cuts off at some point. - User's name is rewritten as 'me'. - The message date format needs only 8 characters (notmuch: 12). - Message count is only displayed when necessary (>=1). - Threads with unread messages are bold (resp. hilighted). - Threads with attachments are marked with an "@". - Threads with mails to user are marked with an ">". - Different colors of tags, message content. All in all, 'notmuch search' is a raw representation of field values, while Sup's search-results-mode shows a polished and terse interpretation of the same values, for human beings, even optimized for the current display width. Now notmuch.el and notmuch.vim just display the output of 'notmuch search', verbatim (perhaps enhanced with coloring based on regexes). I'm experimenting with a notmuch web client (currently 'evenless'), trying to replicate much of the feeling of Sup, in a web client. First, I took the output of 'notmuch search', parsed it and tried to reformat it like Sup. That worked well for all fields but the date field: In contrast to the other fields, notmuch's date representation is intended for direct consumption by humans (english-speaking, that is ;-). I noticed this entry in TODO: Add a "--format" option to "notmuch search", (something printf-like for selecting what gets printed). Since I'm not eager to write a format parser, I started to implement --format as an enumerating option notmuch_format_t. By now, I have NOTMUCH_FORMAT_DEFAULT and NOTMUCH_FORMAT_SUP. do_search_threads() does the real work. In notmuch-time.c, I have implemented an alternative nice and terse time representation, notmuch_time_relative8_date(). I realized, though, that at this point I would have to hardcode things like ANSI coloring into NOTMUCH_FORMAT_SUP. Also, any l10n (e.g. of time representation) would have to be hardcoded as well (btw, anybody knows a library for human readable time representations which supports l10n and i18n?). So perhaps it's better to move the polishing into the client (Yeah! Python to the rescue! ;-). But then, 'notmuch search' would need to return some raw representation of the date field as well. Any comment? Any other thoughts about this? Regards, Gregor Hoffleit
