[PATCH] Output unmodified Content-Type header value for JSON format.
On Sat, 19 Nov 2011 13:58:18 -0500, Austin Clements wrote: > Quoth Dmitry Kurochkin on Nov 19 at 9:26 am: > > On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements > > wrote: > > > Quoth Dmitry Kurochkin on Nov 19 at 6:42 am: > > > > Hi Jamie. > > > > > > > > On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins > > > finestructure.net> wrote: > > > > > On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin > > > > > wrote: > > > > > > Before the change, notmuch used g_mime_content_type_to_string(3) > > > > > > function to output Content-Type header value. Turns out it outputs > > > > > > only "type/subtype" part and ignores all parameters. Also, if there > > > > > > is no Content-Type header, default "text/plain" value is used. > > > > > > > > > > Hi, Dmitry. Can you explain under what circumstances you would need > > > > > the > > > > > extra content-type parameters? > > > > > > > > Charset is an example of a parameter which you need to render a part > > > > correctly. > > > > > > Can notmuch convert to a common charset, given that, otherwise, every > > > client is going to have to implement this conversion anyway? > > > > > > > Notmuch can handle charset (and any other) parameters but only for known > > media types (i.e. text/*). I think it would be useful (especially for > > human-readable output formats). But it is a separate issue. > > > > Notmuch can not convert other types it does not know how to handle. > > E.g. HTML charset conversion is not as simple as for plain text. > > > > AFAIK standard defines charset parameter just for few types. So in > > general, charset parameter can have any meaning for some custom media > > type. > > Interesting. I hadn't realized the content-type specification was so > open-ended. However, there are many things that *could* be included > in the JSON format but aren't; what's included is primarily driven by > what consumers actually need and it seems like the actual need here is > charset handling. Maybe the JSON format *shouldn't* evolve this way, > but I think it should either be driven by its needs like it is now, or > we should be taking bigger steps like providing *all* of the headers > (essentially, a JSON-ification of the MIME structure), which would > subsume more specific generalizations like exposing just the full > content-type header. > I think it is a good idea to provide all headers in JSON output. Still I believe this patch is still valid. It is a simple change, which makes the JSON format simpler and we have consumers that need it. Providing all headers would be a bigger change (and I expect it to be much more difficult to get accepted). What I definately do not like, is adding an exception for charset parameter and inventing complex rules for JSON format instead of keeping it simple. > Regarding charset, specifically, though, the JSON format only includes > part bodies for text/* types and, according to RFC 2045, > > For example, the "charset" parameter is applicable to any subtype of > "text", ... > > Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush, > but I think it's saying essentially the same thing in a lot more > detail. Given that, I think it does make sense for notmuch to handle > the charset parameter and re-coding. > I think it may be a good idea but it is not trivial to do right. We should not just convert all text parts unconditionally to locale or UTF-8. > > > (And are there other examples of useful things in the content type?) > > > > What is meant by useful? All parameters do have some use. The fact > > that notmuch does not handle them does not mean they are useless. And > > notmuch can not handle all parameters just because the list of > > parameters is not defined. So there is no choice but to let notmuch > > users see and use these parameters. > > Yes, I now agree with this, modulo my statements about generality above. > Thanks. Regards, Dmitry > > Regards, > > Dmitry > > > > -- > Austin Clements MIT/'06/PhD/CSAIL > amdragon at mit.edu http://web.mit.edu/amdragon >Somewhere in the dream we call reality you will find me, > searching for the reality we call dreams.
[PATCH] emacs: logically group def{custom,face}s
On Tue, 01 Nov 2011 21:00:28 +0100, Pieter Praet wrote: > > Thanks for testing, Daniel and Jameson! > > It still applies cleanly, so if there's anything preventing it from > being merged in, I'd like to hear about it. > Oops. Some time in the last few weeks, it stopped applying cleanly. d
[PATCH] emacs: breakout notmuch-show-advance functionality from notmuch-show-advance-and-archive
On Sun, 13 Nov 2011 13:16:48 -0800, Jameson Graef Rollins wrote: > This patch breaks out much of the functionality of > notmuch-show-advance-and-archive into a new function: > notmuch-show-advance. This new function does all the advancing > through a show buffer that notmuch-show-advance-and-archive did, > without all the invasive thread archiving. The return value of > notmuch-show-advance is nil if the bottom of the thread is not > reached, and t if it is. Pushed to master d
[PATCH v2] Output unmodified Content-Type header value for JSON format.
On Sat, 19 Nov 2011 08:59:29 -0400, David Bremner wrote: > On Sat, 19 Nov 2011 08:18:41 +0400, Dmitry Kurochkin gmail.com> wrote: > > Before the change, notmuch used g_mime_content_type_to_string(3) > > function to output Content-Type header value. Turns out it outputs > > only "type/subtype" part and ignores all parameters. Also, if there > > is no Content-Type header, default "text/plain" value is used. > > Hi Dmitry; > > I haven't analyzed the substance of your patch yet, but I did have a > couple thoughts while reading your mail. > > - It seems that every time we change the json format, we have a round of > suffering because people are unable to detect a mismatch between their > emacs code and the cli. Not that this is your problem necessarily, but > it would be nice if someone (TM), would come up with some version info > for the json output, and a patch to check it on the emacs side. > IMO this is a good idea. > - The previous point is a bit of a counterargument to this, but in > general, I think I prefer patches that modify the core seperate from > those that do emacs (or python, or ...) stuff. > I couls separate it. I made is a single patch to avoid having a revision with broken emacs UI (and tests). Regards, Dmitry > - I understand you want to make your patches reviewable without applying > by including lots of context, but at a certain point it has actually > the opposite effect for me. I just don't read 900+ line emails ;). Of > course, I can still apply the patch and look at it, so it's really up > to you. > > d
[PATCH] Output unmodified Content-Type header value for JSON format.
Hi Jameson.
On Sat, 19 Nov 2011 02:49:43 -0800, Jameson Graef Rollins wrote:
> On Sat, 19 Nov 2011 06:42:00 +0400, Dmitry Kurochkin gmail.com> wrote:
> > The parameters are there for a reason. They are part of the
> > content-type and are needed to handle the body properly. If you say
> > that the parameters are not needed by notmuch users, that implies that
> > they are handled by notmuch. Which is just not possible.
>
> Hey, Dimitry. At least some of the parameters in the content-type are
> actually related to the mime structure itself. A good example is:
>
> boundary=\"=-=-=\"
>
> This parameter is there to tell the MIME parser how to parse the content
> that follows. It is meant for the first level parser and no more. Once
> the MIME has been separated into it's constituent parts, there's no need
> for any further clients to know anything about boundary string.
>
Yes, at least in most cases. On the other hand, if you can make notmuch
show raw multipart part (you can, right?), then it seems natural that
notmuch provides enough information to parse it.
> I would argue that notmuch is acting as the first level parser. As far
> as I can tell, most of the rest of the parameters I've seen should only
> be useful to the those first-level parsers.
>
I do not think first-level parser is a standard term. As I understand,
you mean that notmuch parses MIME recursively until the leaf non-MIME
parts. Correct?
I do not know what parameters you have seen. The most common example of
a useful parameter for second-level parsers is a charset.
I do not understand why do we try to come up with excuses for not
providing useful information to users. Current assumption that all
parameters that notmuch does not handle are useless is plain invalid.
> As Austin mentioned, is it not possible for notmuch itself to act on the
> parameter to give a properly formatted output to its clients?
>
Please see my answer to Austin. I explained why this is not an option
in general case.
As for parameters that notmuch already handles, like "boundary", I just
do not understand why we should invent some artificial exceptions and
decide for our users what parameters are useful or useless for them
instead of implementing a simple and kind of expected approach:
content-type in JSON is original Content-Type header value. It makes
both the code and the format simpler.
> > The fact that this change happens to fix an issue with HTML charsets for
> > me is just a side effect.
>
> But isn't that actually a large part of the issue? If this patch fixes
> something that you think notmuch is doing improperly, could there not be
> a test for it?
>
No. It just happens to be how I found the problem. The issue is:
notmuch JSON format mangles Content-Type header value by throwing away
useful information in some cases and adding info that was not there in
others. Note that I do not mention any single parameter name here. It
is a general issue, not a "charset" or "boundary" parameter issue.
> However, based on your patches and as far as I can tell, this change
> adds more than a boundary parameter to only crypto parts
> (application/signed and application/encrypted). However, I don't think
> any of the crypto functionality needs any of the extra information
> provided in the extended output. If there was a test for the
> functionality you think is missing, it would help bolster the case for
> the additional output.
>
Again, the patch is not about "add boundary and other useless crypto
parameters". The patch is about stop throwing away useless
information.
> > > > "content": [{"id": 2,
> > > > - "content-type": "text/plain",
> > > > "content": "This is a test signed message.\n"},
> > >
> > > Without figuring out what's going on, I notice that some of the tests
> > > have been modified to remove the content-type fields on a bunch of
> > > parts. I think that is probably not right.
> > >
> >
> > I tried to explain this in the preable. These parts do not have
> > Content-Type in the original message. So I think it is wrong for
> > notmuch JSON format to add it.
>
> Ah, ok, I think I understand this point. I think this is actually a
> separate issue than the one the rest of the patch set is for, though.
> One part of the patch is that content-type parameters are also about,
> and another part is that parts without content-type shouldn't be
> assigned one automatically. I personally think those should be separate
> patches.
>
The implementation makes it not practical to separate these changes.
They come as a result of the same code change.
Regards,
Dmitry
> jamie.
[PATCH] emacs: Avoid unnecessary markers.
This is just cleanup. These markers are all immediately resolved to points by Emacs, so using markers here is just unncessary overhead. --- I originally did this for performance, since Emacs has to scan all un-GC'd markers on every buffer change, but it turns out to matter notmuch. emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index a8e4d62..f15a75b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -805,12 +805,12 @@ non-authors is found, assume that all of the authors match." (goto-char (point-max)) (if (/= (match-beginning 1) line) (insert (concat "Error: Unexpected output from notmuch search:\n" (substring string line (match-beginning 1)) "\n"))) - (let ((beg (point-marker))) + (let ((beg (point))) (notmuch-search-show-result date count authors subject tags) - (notmuch-search-color-line beg (point-marker) tag-list) - (put-text-property beg (point-marker) 'notmuch-search-thread-id thread-id) - (put-text-property beg (point-marker) 'notmuch-search-authors authors) - (put-text-property beg (point-marker) 'notmuch-search-subject subject) + (notmuch-search-color-line beg (point) tag-list) + (put-text-property beg (point) 'notmuch-search-thread-id thread-id) + (put-text-property beg (point) 'notmuch-search-authors authors) + (put-text-property beg (point) 'notmuch-search-subject subject) (if (string= thread-id notmuch-search-target-thread) (progn (set 'found-target beg) -- 1.7.7.2
[PATCH] emacs: Don't record undo information for search or show buffers.
There's no reason to record undo information for read-only, programmatically-constructed buffers. The undo list just chews up memory keeping track of our calls to insert. --- emacs/notmuch-show.el |2 ++ emacs/notmuch.el |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index d5c95d8..7689867 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -843,6 +843,8 @@ buffer." (inhibit-read-only t)) (switch-to-buffer buffer) (notmuch-show-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (setq notmuch-show-thread-id thread-id) (setq notmuch-show-parent-buffer parent-buffer) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index c1827cc..a8e4d62 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -920,6 +920,8 @@ The optional parameters are used as follows: (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (set 'notmuch-search-query-string query) (set 'notmuch-search-oldest-first oldest-first) (set 'notmuch-search-target-thread target-thread) -- 1.7.7.2
[PATCH] fix a double // to single /
--- test/raw |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/test/raw b/test/raw index b7e265a..99d3a3b 100755 --- a/test/raw +++ b/test/raw @@ -1,4 +1,4 @@ -#!/usr//bin/env bash +#!/usr/bin/env bash test_description='notmuch show --format=raw' . ./test-lib.sh -- 1.7.7
Re: [PATCH] dump: Don't sort.
[Thomas Schwinge] +/* This used to use NOTMUCH_SORT_MESSAGE_ID. On 2011-10-29, a measurement + * on a 372981 messages instance showed that wall time can be reduced from + * 28 minutes (sorted by Message-ID) to 15 minutes (unsorted), the latter + * being much more ``database-disk-layout-friendly''. Subsequently sorting + * the 25 MiB of data is a no-brainer, if required. */ This sound like a great idea for my use case. Doing 'notmuch dump' with my 1.2 million emails take hours at the moment (not very fast encrypted file system), and result in a 90 MiB dump file. -- Happy hacking Petter Reinholdtsen ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
Quoth Dmitry Kurochkin on Nov 19 at 9:26 am: On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Dmitry Kurochkin on Nov 19 at 6:42 am: Hi Jamie. On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Before the change, notmuch used g_mime_content_type_to_string(3) function to output Content-Type header value. Turns out it outputs only type/subtype part and ignores all parameters. Also, if there is no Content-Type header, default text/plain value is used. Hi, Dmitry. Can you explain under what circumstances you would need the extra content-type parameters? Charset is an example of a parameter which you need to render a part correctly. Can notmuch convert to a common charset, given that, otherwise, every client is going to have to implement this conversion anyway? Notmuch can handle charset (and any other) parameters but only for known media types (i.e. text/*). I think it would be useful (especially for human-readable output formats). But it is a separate issue. Notmuch can not convert other types it does not know how to handle. E.g. HTML charset conversion is not as simple as for plain text. AFAIK standard defines charset parameter just for few types. So in general, charset parameter can have any meaning for some custom media type. Interesting. I hadn't realized the content-type specification was so open-ended. However, there are many things that *could* be included in the JSON format but aren't; what's included is primarily driven by what consumers actually need and it seems like the actual need here is charset handling. Maybe the JSON format *shouldn't* evolve this way, but I think it should either be driven by its needs like it is now, or we should be taking bigger steps like providing *all* of the headers (essentially, a JSON-ification of the MIME structure), which would subsume more specific generalizations like exposing just the full content-type header. Regarding charset, specifically, though, the JSON format only includes part bodies for text/* types and, according to RFC 2045, For example, the charset parameter is applicable to any subtype of text, ... Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush, but I think it's saying essentially the same thing in a lot more detail. Given that, I think it does make sense for notmuch to handle the charset parameter and re-coding. (And are there other examples of useful things in the content type?) What is meant by useful? All parameters do have some use. The fact that notmuch does not handle them does not mean they are useless. And notmuch can not handle all parameters just because the list of parameters is not defined. So there is no choice but to let notmuch users see and use these parameters. Yes, I now agree with this, modulo my statements about generality above. Regards, Dmitry -- Austin Clements MIT/'06/PhD/CSAIL amdra...@mit.edu http://web.mit.edu/amdragon Somewhere in the dream we call reality you will find me, searching for the reality we call dreams. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Don't link libnotmuch if libutil isn't linked in properly.
On Sun, 13 Nov 2011 11:34:42 -0500, Tom Prince tom.pri...@ualberta.net wrote: For some reason, on my machine, the link is picking up /usr/lib/libutil.so instead of util/libutil.a. This causes there to be undefined symbols in libnotmuch, making it unuseable. This patch causes the link to fail instead. I pushed this to master, let's see if it breaks for anyone. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
Hi Jameson.
On Sat, 19 Nov 2011 02:49:43 -0800, Jameson Graef Rollins
jroll...@finestructure.net wrote:
On Sat, 19 Nov 2011 06:42:00 +0400, Dmitry Kurochkin
dmitry.kuroch...@gmail.com wrote:
The parameters are there for a reason. They are part of the
content-type and are needed to handle the body properly. If you say
that the parameters are not needed by notmuch users, that implies that
they are handled by notmuch. Which is just not possible.
Hey, Dimitry. At least some of the parameters in the content-type are
actually related to the mime structure itself. A good example is:
boundary=\=-=-=\
This parameter is there to tell the MIME parser how to parse the content
that follows. It is meant for the first level parser and no more. Once
the MIME has been separated into it's constituent parts, there's no need
for any further clients to know anything about boundary string.
Yes, at least in most cases. On the other hand, if you can make notmuch
show raw multipart part (you can, right?), then it seems natural that
notmuch provides enough information to parse it.
I would argue that notmuch is acting as the first level parser. As far
as I can tell, most of the rest of the parameters I've seen should only
be useful to the those first-level parsers.
I do not think first-level parser is a standard term. As I understand,
you mean that notmuch parses MIME recursively until the leaf non-MIME
parts. Correct?
I do not know what parameters you have seen. The most common example of
a useful parameter for second-level parsers is a charset.
I do not understand why do we try to come up with excuses for not
providing useful information to users. Current assumption that all
parameters that notmuch does not handle are useless is plain invalid.
As Austin mentioned, is it not possible for notmuch itself to act on the
parameter to give a properly formatted output to its clients?
Please see my answer to Austin. I explained why this is not an option
in general case.
As for parameters that notmuch already handles, like boundary, I just
do not understand why we should invent some artificial exceptions and
decide for our users what parameters are useful or useless for them
instead of implementing a simple and kind of expected approach:
content-type in JSON is original Content-Type header value. It makes
both the code and the format simpler.
The fact that this change happens to fix an issue with HTML charsets for
me is just a side effect.
But isn't that actually a large part of the issue? If this patch fixes
something that you think notmuch is doing improperly, could there not be
a test for it?
No. It just happens to be how I found the problem. The issue is:
notmuch JSON format mangles Content-Type header value by throwing away
useful information in some cases and adding info that was not there in
others. Note that I do not mention any single parameter name here. It
is a general issue, not a charset or boundary parameter issue.
However, based on your patches and as far as I can tell, this change
adds more than a boundary parameter to only crypto parts
(application/signed and application/encrypted). However, I don't think
any of the crypto functionality needs any of the extra information
provided in the extended output. If there was a test for the
functionality you think is missing, it would help bolster the case for
the additional output.
Again, the patch is not about add boundary and other useless crypto
parameters. The patch is about stop throwing away useless
information.
content: [{id: 2,
- content-type: text/plain,
content: This is a test signed message.\n},
Without figuring out what's going on, I notice that some of the tests
have been modified to remove the content-type fields on a bunch of
parts. I think that is probably not right.
I tried to explain this in the preable. These parts do not have
Content-Type in the original message. So I think it is wrong for
notmuch JSON format to add it.
Ah, ok, I think I understand this point. I think this is actually a
separate issue than the one the rest of the patch set is for, though.
One part of the patch is that content-type parameters are also about,
and another part is that parts without content-type shouldn't be
assigned one automatically. I personally think those should be separate
patches.
The implementation makes it not practical to separate these changes.
They come as a result of the same code change.
Regards,
Dmitry
jamie.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH v2] Output unmodified Content-Type header value for JSON format.
On Sat, 19 Nov 2011 08:59:29 -0400, David Bremner da...@tethera.net wrote: On Sat, 19 Nov 2011 08:18:41 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Before the change, notmuch used g_mime_content_type_to_string(3) function to output Content-Type header value. Turns out it outputs only type/subtype part and ignores all parameters. Also, if there is no Content-Type header, default text/plain value is used. Hi Dmitry; I haven't analyzed the substance of your patch yet, but I did have a couple thoughts while reading your mail. - It seems that every time we change the json format, we have a round of suffering because people are unable to detect a mismatch between their emacs code and the cli. Not that this is your problem necessarily, but it would be nice if someone (TM), would come up with some version info for the json output, and a patch to check it on the emacs side. IMO this is a good idea. - The previous point is a bit of a counterargument to this, but in general, I think I prefer patches that modify the core seperate from those that do emacs (or python, or ...) stuff. I couls separate it. I made is a single patch to avoid having a revision with broken emacs UI (and tests). Regards, Dmitry - I understand you want to make your patches reviewable without applying by including lots of context, but at a certain point it has actually the opposite effect for me. I just don't read 900+ line emails ;). Of course, I can still apply the patch and look at it, so it's really up to you. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
On Sat, 19 Nov 2011 13:58:18 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Dmitry Kurochkin on Nov 19 at 9:26 am: On Fri, 18 Nov 2011 23:59:57 -0500, Austin Clements amdra...@mit.edu wrote: Quoth Dmitry Kurochkin on Nov 19 at 6:42 am: Hi Jamie. On Fri, 18 Nov 2011 17:58:52 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: On Sat, 19 Nov 2011 03:45:05 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Before the change, notmuch used g_mime_content_type_to_string(3) function to output Content-Type header value. Turns out it outputs only type/subtype part and ignores all parameters. Also, if there is no Content-Type header, default text/plain value is used. Hi, Dmitry. Can you explain under what circumstances you would need the extra content-type parameters? Charset is an example of a parameter which you need to render a part correctly. Can notmuch convert to a common charset, given that, otherwise, every client is going to have to implement this conversion anyway? Notmuch can handle charset (and any other) parameters but only for known media types (i.e. text/*). I think it would be useful (especially for human-readable output formats). But it is a separate issue. Notmuch can not convert other types it does not know how to handle. E.g. HTML charset conversion is not as simple as for plain text. AFAIK standard defines charset parameter just for few types. So in general, charset parameter can have any meaning for some custom media type. Interesting. I hadn't realized the content-type specification was so open-ended. However, there are many things that *could* be included in the JSON format but aren't; what's included is primarily driven by what consumers actually need and it seems like the actual need here is charset handling. Maybe the JSON format *shouldn't* evolve this way, but I think it should either be driven by its needs like it is now, or we should be taking bigger steps like providing *all* of the headers (essentially, a JSON-ification of the MIME structure), which would subsume more specific generalizations like exposing just the full content-type header. I think it is a good idea to provide all headers in JSON output. Still I believe this patch is still valid. It is a simple change, which makes the JSON format simpler and we have consumers that need it. Providing all headers would be a bigger change (and I expect it to be much more difficult to get accepted). What I definately do not like, is adding an exception for charset parameter and inventing complex rules for JSON format instead of keeping it simple. Regarding charset, specifically, though, the JSON format only includes part bodies for text/* types and, according to RFC 2045, For example, the charset parameter is applicable to any subtype of text, ... Section 4.1.2 (Charset Parameter) of RFC 2046 beats around the bush, but I think it's saying essentially the same thing in a lot more detail. Given that, I think it does make sense for notmuch to handle the charset parameter and re-coding. I think it may be a good idea but it is not trivial to do right. We should not just convert all text parts unconditionally to locale or UTF-8. (And are there other examples of useful things in the content type?) What is meant by useful? All parameters do have some use. The fact that notmuch does not handle them does not mean they are useless. And notmuch can not handle all parameters just because the list of parameters is not defined. So there is no choice but to let notmuch users see and use these parameters. Yes, I now agree with this, modulo my statements about generality above. Thanks. Regards, Dmitry Regards, Dmitry -- Austin Clements MIT/'06/PhD/CSAIL amdra...@mit.edu http://web.mit.edu/amdragon Somewhere in the dream we call reality you will find me, searching for the reality we call dreams. ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] Output unmodified Content-Type header value for JSON format.
On Sun, 20 Nov 2011 22:32:53 +0400, Dmitry Kurochkin dmitry.kuroch...@gmail.com wrote: Yes, at least in most cases. On the other hand, if you can make notmuch show raw multipart part (you can, right?), then it seems natural that notmuch provides enough information to parse it. This is kind of an unresolved issue, actually. Currently headers are only included in the raw format output of an entire message. Otherwise, when raw output is requested of an individual part only the body is output. For multipart parts, the raw format output includes all body parts concatenated together, still without any headers. This raw multipart output clearly doesn't really make much sense and we need to figure that out. dkg wrote a good breakdown of the issue here: id:4e09072a.7040...@fifthhorseman.net However, this only for raw output. It's definitely not the same as the json output. For json the parts are all parsed by notmuch and placed into separate json elements. The receiver is not going to do any further parsing since all the mime structure parsing has been done. We need to keep clear the distinction between parsing the mime structure, and encoding the content of the part. Confusion seems to be coming from the fact that the Content-Type header includes information needed for both mime parsing and content encoding. However, I don't think that means that we need to just include everything in the output. Parameters that have to do with mime parsing should be dropped, since that information has already been used in the mime parsing and can't is no longer useful to the consumer. It's just noise, and I don't think notmuch should be outputting useless noise. The open question seems to be how we handle the content encoding parameters. My argument is that those should either be used by notmuch to properly encode the content for the consumer. If that's not possible, then just those parameters needed by the consumer to decode the content should be output. But isn't that actually a large part of the issue? If this patch fixes something that you think notmuch is doing improperly, could there not be a test for it? No. It just happens to be how I found the problem. The issue is: notmuch JSON format mangles Content-Type header value by throwing away useful information in some cases and adding info that was not there in others. Note that I do not mention any single parameter name here. It is a general issue, not a charset or boundary parameter issue. I'm sorry, but I still don't believe it's not possible to test for this issue. If there's a problem that you're seeing, then you must of identified it somehow, and therefore there must be a way to test for it. jamie. pgpXH3DgFKp8r.pgp Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] fix a double // to single /
--- test/raw |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/test/raw b/test/raw index b7e265a..99d3a3b 100755 --- a/test/raw +++ b/test/raw @@ -1,4 +1,4 @@ -#!/usr//bin/env bash +#!/usr/bin/env bash test_description='notmuch show --format=raw' . ./test-lib.sh -- 1.7.7 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Don't record undo information for search or show buffers.
There's no reason to record undo information for read-only, programmatically-constructed buffers. The undo list just chews up memory keeping track of our calls to insert. --- emacs/notmuch-show.el |2 ++ emacs/notmuch.el |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index d5c95d8..7689867 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -843,6 +843,8 @@ buffer. (inhibit-read-only t)) (switch-to-buffer buffer) (notmuch-show-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (setq notmuch-show-thread-id thread-id) (setq notmuch-show-parent-buffer parent-buffer) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index c1827cc..a8e4d62 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -920,6 +920,8 @@ The optional parameters are used as follows: (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (set 'notmuch-search-query-string query) (set 'notmuch-search-oldest-first oldest-first) (set 'notmuch-search-target-thread target-thread) -- 1.7.7.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
[PATCH] emacs: Avoid unnecessary markers.
This is just cleanup. These markers are all immediately resolved to points by Emacs, so using markers here is just unncessary overhead. --- I originally did this for performance, since Emacs has to scan all un-GC'd markers on every buffer change, but it turns out to matter notmuch. emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index a8e4d62..f15a75b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -805,12 +805,12 @@ non-authors is found, assume that all of the authors match. (goto-char (point-max)) (if (/= (match-beginning 1) line) (insert (concat Error: Unexpected output from notmuch search:\n (substring string line (match-beginning 1)) \n))) - (let ((beg (point-marker))) + (let ((beg (point))) (notmuch-search-show-result date count authors subject tags) - (notmuch-search-color-line beg (point-marker) tag-list) - (put-text-property beg (point-marker) 'notmuch-search-thread-id thread-id) - (put-text-property beg (point-marker) 'notmuch-search-authors authors) - (put-text-property beg (point-marker) 'notmuch-search-subject subject) + (notmuch-search-color-line beg (point) tag-list) + (put-text-property beg (point) 'notmuch-search-thread-id thread-id) + (put-text-property beg (point) 'notmuch-search-authors authors) + (put-text-property beg (point) 'notmuch-search-subject subject) (if (string= thread-id notmuch-search-target-thread) (progn (set 'found-target beg) -- 1.7.7.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Don't record undo information for search or show buffers.
On Sun, 20 Nov 2011 20:00:55 -0500, Austin Clements amdra...@mit.edu wrote: There's no reason to record undo information for read-only, programmatically-constructed buffers. The undo list just chews up memory keeping track of our calls to insert. Makes sense and looks good! Regards, Dmitry --- emacs/notmuch-show.el |2 ++ emacs/notmuch.el |2 ++ 2 files changed, 4 insertions(+), 0 deletions(-) diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el index d5c95d8..7689867 100644 --- a/emacs/notmuch-show.el +++ b/emacs/notmuch-show.el @@ -843,6 +843,8 @@ buffer. (inhibit-read-only t)) (switch-to-buffer buffer) (notmuch-show-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (setq notmuch-show-thread-id thread-id) (setq notmuch-show-parent-buffer parent-buffer) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index c1827cc..a8e4d62 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -920,6 +920,8 @@ The optional parameters are used as follows: (let ((buffer (get-buffer-create (notmuch-search-buffer-title query (switch-to-buffer buffer) (notmuch-search-mode) +;; Don't track undo information for this buffer +(set 'buffer-undo-list t) (set 'notmuch-search-query-string query) (set 'notmuch-search-oldest-first oldest-first) (set 'notmuch-search-target-thread target-thread) -- 1.7.7.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: Avoid unnecessary markers.
On Sun, 20 Nov 2011 20:07:02 -0500, Austin Clements amdra...@mit.edu wrote: This is just cleanup. These markers are all immediately resolved to points by Emacs, so using markers here is just unncessary overhead. --- I originally did this for performance, since Emacs has to scan all un-GC'd markers on every buffer change, but it turns out to matter notmuch. Again, makes sense and looks good. Regads, Dmitry emacs/notmuch.el | 10 +- 1 files changed, 5 insertions(+), 5 deletions(-) diff --git a/emacs/notmuch.el b/emacs/notmuch.el index a8e4d62..f15a75b 100644 --- a/emacs/notmuch.el +++ b/emacs/notmuch.el @@ -805,12 +805,12 @@ non-authors is found, assume that all of the authors match. (goto-char (point-max)) (if (/= (match-beginning 1) line) (insert (concat Error: Unexpected output from notmuch search:\n (substring string line (match-beginning 1)) \n))) - (let ((beg (point-marker))) + (let ((beg (point))) (notmuch-search-show-result date count authors subject tags) - (notmuch-search-color-line beg (point-marker) tag-list) - (put-text-property beg (point-marker) 'notmuch-search-thread-id thread-id) - (put-text-property beg (point-marker) 'notmuch-search-authors authors) - (put-text-property beg (point-marker) 'notmuch-search-subject subject) + (notmuch-search-color-line beg (point) tag-list) + (put-text-property beg (point) 'notmuch-search-thread-id thread-id) + (put-text-property beg (point) 'notmuch-search-authors authors) + (put-text-property beg (point) 'notmuch-search-subject subject) (if (string= thread-id notmuch-search-target-thread) (progn (set 'found-target beg) -- 1.7.7.2 ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: breakout notmuch-show-advance functionality from notmuch-show-advance-and-archive
On Sun, 13 Nov 2011 13:16:48 -0800, Jameson Graef Rollins jroll...@finestructure.net wrote: This patch breaks out much of the functionality of notmuch-show-advance-and-archive into a new function: notmuch-show-advance. This new function does all the advancing through a show buffer that notmuch-show-advance-and-archive did, without all the invasive thread archiving. The return value of notmuch-show-advance is nil if the bottom of the thread is not reached, and t if it is. Pushed to master d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
Re: [PATCH] emacs: logically group def{custom,face}s
On Tue, 01 Nov 2011 21:00:28 +0100, Pieter Praet pie...@praet.org wrote: Thanks for testing, Daniel and Jameson! It still applies cleanly, so if there's anything preventing it from being merged in, I'd like to hear about it. Oops. Some time in the last few weeks, it stopped applying cleanly. d ___ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch
