priorities for 0.13

[Mark Walters]

On Sun, 29 Apr 2012, David Bremner  wrote:
> David Bremner  writes:
>
>> Hi All;
>>
>> I'd like to have a feature freeze for 0.13 sometime in the first week of
>> May.  What do people feel are priorities to try to get reviewed and
>> pushed for 0.13?
>>
>
> So here are some patches that people expressed interest in for 0.13, but
> need more review.
>
>  id:"1335056093-17621-1-git-send-email-awg+notmuch at xvx.ca"
>
>  id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com"
>
>  id:"1335651473-19652-1-git-send-email-amdragon at mit.edu"
>
> Note that in particular it makes sense to push amdragon's changes while
> we are bumping the SONAME.
> 
> The sequence by Jamie
>
> id:"1334429574-12918-2-git-send-email-jrollins at finestructure.net"
>
> Has only one minor comment about a comment; I'm not sure it's enough for
> a rebase on it's own.  Mark, what do you think?

Hi

I think Jamie already posted a patch with a nicer comment 

id:"1334436547-10260-1-git-send-email-jrollins at finestructure.net"

(ie that replaces 2/5 in the original series)

In any case don't let the comment hold everything up: we can correct
that later if we care (and it does not matter to users)

Best wishes

Mark

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Austin Clements]

I haven't really looked at this series yet, but I do have a quick
high-level question.  Why use separate customization variables for the
colors in search and show mode?  Wouldn't it make more sense to set
the colors just once and use them in both modes?

BTW, I like how this clearly distinguishes tags and flags.  I wonder
if we could transition to flags for some information that's current
shoe-horned into tags but actually represents immutable information
about a message (attachment, signed, and encrypted or so).

My one concern is that there's a common tag called "flagged", so this
might be overloading terminology.

Quoth Mark Walters on Apr 29 at 11:48 pm:
> This is a rebased (but otherwise unchanged) version of
> id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com".
> 
> It's probably too late for 0.13 but in case anyone would like to look
> at it this version applies cleanly to master so should be easier to
> test.
> 
> The first two patches are basically David Edmondson's patch
> id:"1325006003-27152-1-git-send-email-dme at dme.org".
> 
> Best wishes
> 
> Mark
> 
> 
> Mark Walters (3):
>   emacs: Move colour line from search to lib
>   emacs: Add `notmuch-show-line-faces' and apply it.
>   emacs: allow notmuch-show-line-faces to use flags for colouring
> 
>  emacs/notmuch-lib.el  |   18 ++
>  emacs/notmuch-show.el |   44 
>  emacs/notmuch.el  |   15 +--
>  3 files changed, 59 insertions(+), 18 deletions(-)

priorities for 0.13

[David Bremner]

Mark Walters  writes:
>
> Hi
>
> I think Jamie already posted a patch with a nicer comment 
>
> id:"1334436547-10260-1-git-send-email-jrollins at finestructure.net"
>
> (ie that replaces 2/5 in the original series)

Oh, yeah, I just got lost in the thread. OK, that series is pushed.

d

priorities for 0.13

[David Bremner]

David Bremner  writes:

> Hi All;
>
> I'd like to have a feature freeze for 0.13 sometime in the first week of
> May.  What do people feel are priorities to try to get reviewed and
> pushed for 0.13?
>

So here are some patches that people expressed interest in for 0.13, but
need more review.

 id:"1335056093-17621-1-git-send-email-awg+notmuch at xvx.ca"

 id:"1334431301-27303-1-git-send-email-markwalters1009 at gmail.com"

 id:"1335651473-19652-1-git-send-email-amdragon at mit.edu"

Note that in particular it makes sense to push amdragon's changes while
we are bumping the SONAME.

The sequence by Jamie

id:"1334429574-12918-2-git-send-email-jrollins at finestructure.net"

Has only one minor comment about a comment; I'm not sure it's enough for
a rebase on it's own.  Mark, what do you think?

d

[PATCH 1/3] NEWS: untabified and added file local variables block

[David Bremner]

Tomi Ollila  writes:

> Changed all tabs to 8 spaces (M-x untabify over region of the
> whole file).

All three of these look OK to me. I do wonder whether we should call the
file NEWS.mdwn or something like that if we intend to enforce markdown
in it.

d

[PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

Thomas Jost  writes:
> AFAICT, Emacs 23 is just buggy in this case. By reading the code of
> message-send-and-exit and message-bury [1], here is what happens when
> you call message-send-buffer-and-exit with message-kill-buffer-on-exit
> set to nil:
> - message is sent
> - buffer is buried with burry-buffer
> - message-bury: if the window is dedicated and its frame not the only
>   visible frame, then this frame is deleted

OK, I guess I can live with the behaviour as an emacs 23 bug, but I
think we should warn the user of this bug somewhere prominently, perhaps
in the customize message. Effectively users of emacs23 and emacsclient
will probably want to avoid the "new-window" setting.

d

[RFC] Use JSON in emacs interface

[Austin Clements]

Quoth Chris Gray on Apr 29 at 10:22 am:
> Hi,
> 
> My thinking about this arises from the fact that there is a person on
> one of the lists that I read who puts a semicolon after his name.  Of
> course, this confuses the regex in notmuch-search-process-filter, which
> expects that the first semicolon in the string representing a thread is
> after all the authors.
> 
> I first thought of changing the regex so that it looked for the last
> semicolon in the string or something like that, but that would just move
> the problem.  (Semicolons are probably more frequent in subject lines
> than in author names.)  So it seems to me that what is needed is for
> notmuch and emacs to talk with each other in a format that is
> unambiguously parseable.  Since notmuch search already has the option of
> outputting to JSON, that seems like a natural fit.
> 
> Emacs has an existing JSON parser,
> ,
> but it doesn't appear that it is able to parse progressively, meaning
> that it wouldn't be able to display results as they come in from notmuch
> search if used as-is.  My guess is that its parts could be hacked
> together to overcome this limitation though.
> 
> Anyway, if others think this is a good idea, I'm willing to do the
> coding.

This is definitely a good idea.  In fact, there's been quite a bit of
discussion about it in the past, and even some (very old and
outdated) implementation work:

  id:"878vs28dvo.fsf at praet.org"
A rather lengthy discussion of another motivation for using JSON
search.  Includes performance results for using JSON in search.

  id:"20120214152114.GQ27039 at mit.edu"
Discussion of "framed" JSON that would be a valid JSON object, but
could easily be consumed in a streaming fashion without hacking
Emacs' JSON parser or resorting to paging.

  id:"1290777202-14040-1-git-send-email-dme at dme.org"
The implementation from long ago.  Definitely outdated, but could
be a good starting point.

It looks like most of the discussion about streaming JSON parsing has
been on the IRC channel, rather than the mailing list, but I'd be
happy to summarize it or dig out the IRC logs.  

I agree with Adam that it probably makes the most sense to get an
implementation working without streaming first and then add streaming
support.

[PATCH 0/6] Make notmuch_database_{open, create} return status codes

[Justus Winter]

Hi Austin :)

Quoting Austin Clements (2012-04-29 00:17:47)
> Since we're breaking binary and source compatibility with the next
> release anyway, it's about time we fix notmuch_database_{open,create}
> to return status codes.

Awesome, thanks for taking care of this. The python patch looks fine.

Justus

[RFC] Use JSON in emacs interface

[Adam Wolfe Gordon]

Hi Chris,

On Sun, Apr 29, 2012 at 10:22, Chris Gray  wrote:
> I first thought of changing the regex so that it looked for the last
> semicolon in the string or something like that, but that would just move
> the problem. ?(Semicolons are probably more frequent in subject lines
> than in author names.) ?So it seems to me that what is needed is for
> notmuch and emacs to talk with each other in a format that is
> unambiguously parseable. ?Since notmuch search already has the option of
> outputting to JSON, that seems like a natural fit.
>
> Emacs has an existing JSON parser,
> ,
> but it doesn't appear that it is able to parse progressively, meaning
> that it wouldn't be able to display results as they come in from notmuch
> search if used as-is. ?My guess is that its parts could be hacked
> together to overcome this limitation though.
>
> Anyway, if others think this is a good idea, I'm willing to do the
> coding.

I think this is a great idea. If you look at notmuch-mua.el and
notmuch-query.el, you'll see that we already use json.el for reply and
parts of show.

As for parsing progressively to show search results as they arrive,
I'd be inclined to instead implement paging, so emacs could ask for
just the first n results, display them, then ask for the next n
results, etc. Or maybe ask for the results grouped, so that there
would be a valid JSON object for the first n results, then another for
the next n, etc. This might be a tricky thing to design and implement,
but I think it's been discussed before as something that would be nice
to have.

Personally, I think it would be fine to implement the JSON search
first, then deal with progressive parsing and/or grouping, but others
may differ here. Either way, I'd be happy to review patches for this
and offer any suggestions.

-- Adam

[PATCH] NEWS: add news item for 'config list'

[Peter Wang]

---
 NEWS |5 +
 1 files changed, 5 insertions(+), 0 deletions(-)

diff --git a/NEWS b/NEWS
index a2cd080..4f36dff 100644
--- a/NEWS
+++ b/NEWS
@@ -52,6 +52,11 @@ Raw show format changes
   encoded in the original message, including the part's headers.  Leaf
   parts, as before, output the part's transfer-decoded body.

+Listing configuration items
+
+  The new "config list" command prints out all configuration items and
+  their values.
+
 Emacs Interface
 ---

-- 
1.7.4.4

[RFC] Use JSON in emacs interface

[Chris Gray]

Hi,

My thinking about this arises from the fact that there is a person on
one of the lists that I read who puts a semicolon after his name.  Of
course, this confuses the regex in notmuch-search-process-filter, which
expects that the first semicolon in the string representing a thread is
after all the authors.

I first thought of changing the regex so that it looked for the last
semicolon in the string or something like that, but that would just move
the problem.  (Semicolons are probably more frequent in subject lines
than in author names.)  So it seems to me that what is needed is for
notmuch and emacs to talk with each other in a format that is
unambiguously parseable.  Since notmuch search already has the option of
outputting to JSON, that seems like a natural fit.

Emacs has an existing JSON parser,
,
but it doesn't appear that it is able to parse progressively, meaning
that it wouldn't be able to display results as they come in from notmuch
search if used as-is.  My guess is that its parts could be hacked
together to overcome this limitation though.

Anyway, if others think this is a good idea, I'm willing to do the
coding.

Cheers,
Chris

[ANN] New awesome vim plug-in using Ruby bindings

[Alex Ghitza]

Felipe Contreras wrote:
> > vim -c ':NotMuchR'
> >
> > all I get is an error message:
> >
> > Error detected while processing command line:
> > E492: Not an editor command: :NotMuchR
> 
> I don't know if you did anything special to get the normal plug-in to
> work. Maybe you are doing 'source ~/.vim/plugin/notmuch.vim' directly
> in your .vimrc, if so, you can try to do the same with notmuch vim
> ruby. What I have is 'filetype plugin on'.

After banging my head against the wall a bit more, I realised what
should have been obvious from the beginning: I need to have vim built
with ruby support.  So after grabbing the vim source and

./configure --enable-rubyinterp

I am now happily writing this from notmuch-ruby.  As obvious as this
should have been, do you think it deserves a short sentence at the top
of the == install == section of your README?


-- 
Best,
Alex

Alex Ghitza -- http://aghitza.org/
Lecturer in Mathematics -- The University of Melbourne -- Australia

[Patch v4 2/3] emacs: add a filter option to show

[Mark Walters]

Show the current thread with a different filter (i.e., open messages
in the thread matching the new query).

Bound to 'l' for "limit".

Note that it is not the same as filter in search mode as it replaces
the existing query rather than ANDing with it (but it does keep the
thread-id part of the query).
---
 emacs/notmuch-show.el |   12 
 1 files changed, 12 insertions(+), 0 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 3bd9a64..f52a96d 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -42,6 +42,7 @@
 (declare-function notmuch-search-next-thread "notmuch" nil)
 (declare-function notmuch-search-show-thread "notmuch" nil)
 (declare-function notmuch-update-tags "notmuch" (current-tags tag-changes))
+(declare-function notmuch-read-query "notmuch" (prompt))

 (defcustom notmuch-message-headers '("Subject" "To" "Cc" "Date")
   "Headers that should be shown in a message, in this order.
@@ -1161,6 +1162,7 @@ reset based on the original query."
(define-key map "s" 'notmuch-search)
(define-key map "m" 'notmuch-mua-new-mail)
(define-key map "f" 'notmuch-show-forward-message)
+   (define-key map "l" 'notmuch-show-filter-thread)
(define-key map "r" 'notmuch-show-reply-sender)
(define-key map "R" 'notmuch-show-reply)
(define-key map "|" 'notmuch-show-pipe-message)
@@ -1403,6 +1405,16 @@ current thread."
   "Mark the current message as read."
   (notmuch-show-tag-message "-unread"))

+(defun notmuch-show-filter-thread (query)
+  "Filter or LIMIT the current thread based on a new query string.
+
+Reshows the current thread with matches defined by the new query-string."
+  (interactive (list (notmuch-read-query "Filter thread: ")))
+  (let ((msg-id (notmuch-show-get-message-id)))
+(setq notmuch-show-query-context (if (string= query "") nil query))
+(notmuch-show-refresh-view t)
+(notmuch-show-goto-message msg-id)))
+
 ;; Functions for getting attributes of several messages in the current
 ;; thread.

-- 
1.7.9.1

[Patch v4 1/3] emacs: split notmuch-show-apply-state

[Mark Walters]

Separate out a notmuch-show-goto-msg-id sub-function from
notmuch-show-apply-state. There should be no functional change but the
next patch will call the new function.
---
 emacs/notmuch-show.el |   18 +++---
 1 files changed, 11 insertions(+), 7 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 30b26d1..3bd9a64 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1085,6 +1085,16 @@ This includes:
  - the current message."
   (list (notmuch-show-get-message-id) 
(notmuch-show-get-message-ids-for-open-messages)))

+(defun notmuch-show-goto-message (msg-id)
+  "Go to message with msg-id."
+  (goto-char (point-min))
+  (unless (loop if (string= msg-id (notmuch-show-get-message-id))
+   return t
+   until (not (notmuch-show-goto-message-next)))
+(goto-char (point-min))
+(message "Message-id not found."))
+  (notmuch-show-message-adjust))
+
 (defun notmuch-show-apply-state (state)
   "Apply STATE to the current buffer.

@@ -1102,13 +1112,7 @@ This includes:
  until (not (notmuch-show-goto-message-next)))

 ;; Go to the previously open message.
-(goto-char (point-min))
-(unless (loop if (string= current (notmuch-show-get-message-id))
- return t
- until (not (notmuch-show-goto-message-next)))
-  (goto-char (point-min))
-  (message "Previously current message not found."))
-(notmuch-show-message-adjust)))
+(notmuch-show-goto-message current)))

 (defun notmuch-show-refresh-view ( reset-state)
   "Refresh the current view.
-- 
1.7.9.1

[Patch v4 0/3] Add filter to emacs show mode

[Mark Walters]

This is version 4 of the patch set allowing the user to "filter" which
messages are open in emacs show mode. The previous version was at
id:"1335467689-6513-1-git-send-email-markwalters1009 at gmail.com"

The change in this version is to keep position in the thread (at least
to the same message). 

The first patch (new in this series) just splits out a sub-function
notmuch-show-goto-msg-id from notmuch-show-apply-state.

The second patch is almost the same as the first patch in the previous
series but uses the new notmuch-show-goto-msg-id function to maintain
position in the thread.

The final patch is identical to the final patch of the previous series
which moves the key-binding for filter in emacs search mode to 'l' to
match the new binding in show-mode.

Best wishes

Mark



Mark Walters (3):
  emacs: split notmuch-show-apply-state
  emacs: add a filter option to show
  emacs: Bind filter in search to 'l'

 emacs/notmuch-show.el |   30 +++---
 emacs/notmuch.el  |4 ++--
 2 files changed, 25 insertions(+), 9 deletions(-)

-- 
1.7.9.1

[PATCH v2] emacs: do not modify subject in search or show

[David Bremner]

Jameson Graef Rollins  writes:
> A previous patch [0] replaced blank subject lines with '[No Subject]'
> in search and show mode.  

pushed.

d

[RFC] Use JSON in emacs interface

[Chris Gray]

Hi,

My thinking about this arises from the fact that there is a person on
one of the lists that I read who puts a semicolon after his name.  Of
course, this confuses the regex in notmuch-search-process-filter, which
expects that the first semicolon in the string representing a thread is
after all the authors.

I first thought of changing the regex so that it looked for the last
semicolon in the string or something like that, but that would just move
the problem.  (Semicolons are probably more frequent in subject lines
than in author names.)  So it seems to me that what is needed is for
notmuch and emacs to talk with each other in a format that is
unambiguously parseable.  Since notmuch search already has the option of
outputting to JSON, that seems like a natural fit.

Emacs has an existing JSON parser,
http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/lisp/json.el?root=emacs,
but it doesn't appear that it is able to parse progressively, meaning
that it wouldn't be able to display results as they come in from notmuch
search if used as-is.  My guess is that its parts could be hacked
together to overcome this limitation though.

Anyway, if others think this is a good idea, I'm willing to do the
coding.

Cheers,
Chris
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [RFC] Use JSON in emacs interface

[Adam Wolfe Gordon]

Hi Chris,

On Sun, Apr 29, 2012 at 10:22, Chris Gray chrismg...@gmail.com wrote:
 I first thought of changing the regex so that it looked for the last
 semicolon in the string or something like that, but that would just move
 the problem.  (Semicolons are probably more frequent in subject lines
 than in author names.)  So it seems to me that what is needed is for
 notmuch and emacs to talk with each other in a format that is
 unambiguously parseable.  Since notmuch search already has the option of
 outputting to JSON, that seems like a natural fit.

 Emacs has an existing JSON parser,
 http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/lisp/json.el?root=emacs,
 but it doesn't appear that it is able to parse progressively, meaning
 that it wouldn't be able to display results as they come in from notmuch
 search if used as-is.  My guess is that its parts could be hacked
 together to overcome this limitation though.

 Anyway, if others think this is a good idea, I'm willing to do the
 coding.

I think this is a great idea. If you look at notmuch-mua.el and
notmuch-query.el, you'll see that we already use json.el for reply and
parts of show.

As for parsing progressively to show search results as they arrive,
I'd be inclined to instead implement paging, so emacs could ask for
just the first n results, display them, then ask for the next n
results, etc. Or maybe ask for the results grouped, so that there
would be a valid JSON object for the first n results, then another for
the next n, etc. This might be a tricky thing to design and implement,
but I think it's been discussed before as something that would be nice
to have.

Personally, I think it would be fine to implement the JSON search
first, then deal with progressive parsing and/or grouping, but others
may differ here. Either way, I'd be happy to review patches for this
and offer any suggestions.

-- Adam
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH v3 1/4] emacs: Let the user choose where to compose new mails

[David Bremner]

Thomas Jost schno...@schnouki.net writes:
 AFAICT, Emacs 23 is just buggy in this case. By reading the code of
 message-send-and-exit and message-bury [1], here is what happens when
 you call message-send-buffer-and-exit with message-kill-buffer-on-exit
 set to nil:
 - message is sent
 - buffer is buried with burry-buffer
 - message-bury: if the window is dedicated and its frame not the only
   visible frame, then this frame is deleted

OK, I guess I can live with the behaviour as an emacs 23 bug, but I
think we should warn the user of this bug somewhere prominently, perhaps
in the customize message. Effectively users of emacs23 and emacsclient
will probably want to avoid the new-window setting.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [PATCH 1/3] NEWS: untabified and added file local variables block

[David Bremner]

Tomi Ollila tomi.oll...@iki.fi writes:

 Changed all tabs to 8 spaces (M-x untabify over region of the
 whole file).

All three of these look OK to me. I do wonder whether we should call the
file NEWS.mdwn or something like that if we intend to enforce markdown
in it.

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: priorities for 0.13

[David Bremner]

David Bremner da...@tethera.net writes:

 Hi All;

 I'd like to have a feature freeze for 0.13 sometime in the first week of
 May.  What do people feel are priorities to try to get reviewed and
 pushed for 0.13?


So here are some patches that people expressed interest in for 0.13, but
need more review.

 id:1335056093-17621-1-git-send-email-awg+notm...@xvx.ca

 id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com

 id:1335651473-19652-1-git-send-email-amdra...@mit.edu

Note that in particular it makes sense to push amdragon's changes while
we are bumping the SONAME.

The sequence by Jamie

id:1334429574-12918-2-git-send-email-jroll...@finestructure.net

Has only one minor comment about a comment; I'm not sure it's enough for
a rebase on it's own.  Mark, what do you think?

d
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: priorities for 0.13

[Mark Walters]

On Sun, 29 Apr 2012, David Bremner da...@tethera.net wrote:
 David Bremner da...@tethera.net writes:

 Hi All;

 I'd like to have a feature freeze for 0.13 sometime in the first week of
 May.  What do people feel are priorities to try to get reviewed and
 pushed for 0.13?


 So here are some patches that people expressed interest in for 0.13, but
 need more review.

  id:1335056093-17621-1-git-send-email-awg+notm...@xvx.ca

  id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com

  id:1335651473-19652-1-git-send-email-amdra...@mit.edu

 Note that in particular it makes sense to push amdragon's changes while
 we are bumping the SONAME.
 
 The sequence by Jamie

 id:1334429574-12918-2-git-send-email-jroll...@finestructure.net

 Has only one minor comment about a comment; I'm not sure it's enough for
 a rebase on it's own.  Mark, what do you think?

Hi

I think Jamie already posted a patch with a nicer comment 

id:1334436547-10260-1-git-send-email-jroll...@finestructure.net

(ie that replaces 2/5 in the original series)

In any case don't let the comment hold everything up: we can correct
that later if we care (and it does not matter to users)

Best wishes

Mark
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [RFC] Use JSON in emacs interface

[Austin Clements]

Quoth Chris Gray on Apr 29 at 10:22 am:
 Hi,
 
 My thinking about this arises from the fact that there is a person on
 one of the lists that I read who puts a semicolon after his name.  Of
 course, this confuses the regex in notmuch-search-process-filter, which
 expects that the first semicolon in the string representing a thread is
 after all the authors.
 
 I first thought of changing the regex so that it looked for the last
 semicolon in the string or something like that, but that would just move
 the problem.  (Semicolons are probably more frequent in subject lines
 than in author names.)  So it seems to me that what is needed is for
 notmuch and emacs to talk with each other in a format that is
 unambiguously parseable.  Since notmuch search already has the option of
 outputting to JSON, that seems like a natural fit.
 
 Emacs has an existing JSON parser,
 http://cvs.savannah.gnu.org/viewvc/*checkout*/emacs/lisp/json.el?root=emacs,
 but it doesn't appear that it is able to parse progressively, meaning
 that it wouldn't be able to display results as they come in from notmuch
 search if used as-is.  My guess is that its parts could be hacked
 together to overcome this limitation though.
 
 Anyway, if others think this is a good idea, I'm willing to do the
 coding.

This is definitely a good idea.  In fact, there's been quite a bit of
discussion about it in the past, and even some (very old and
outdated) implementation work:

  id:878vs28dvo@praet.org
A rather lengthy discussion of another motivation for using JSON
search.  Includes performance results for using JSON in search.

  id:20120214152114.gq27...@mit.edu
Discussion of framed JSON that would be a valid JSON object, but
could easily be consumed in a streaming fashion without hacking
Emacs' JSON parser or resorting to paging.

  id:1290777202-14040-1-git-send-email-...@dme.org
The implementation from long ago.  Definitely outdated, but could
be a good starting point.

It looks like most of the discussion about streaming JSON parsing has
been on the IRC channel, rather than the mailing list, but I'd be
happy to summarize it or dig out the IRC logs.  

I agree with Adam that it probably makes the most sense to get an
implementation working without streaming first and then add streaming
support.
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

This is a rebased (but otherwise unchanged) version of
id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.

It's probably too late for 0.13 but in case anyone would like to look
at it this version applies cleanly to master so should be easier to
test.

The first two patches are basically David Edmondson's patch
id:1325006003-27152-1-git-send-email-...@dme.org.

Best wishes

Mark


Mark Walters (3):
  emacs: Move colour line from search to lib
  emacs: Add `notmuch-show-line-faces' and apply it.
  emacs: allow notmuch-show-line-faces to use flags for colouring

 emacs/notmuch-lib.el  |   18 ++
 emacs/notmuch-show.el |   44 
 emacs/notmuch.el  |   15 +--
 3 files changed, 59 insertions(+), 18 deletions(-)

-- 
1.7.9.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 1/3] emacs: Move colour line from search to lib

[Mark Walters]

This patch moves the overlay/colouring from notmuch.el to
notmuch-lib.el. This is in preparation for its use by notmuch-show in
the next patch. This is just a rebased version of the emacs/notmuch.el
and emacs/notmuch-lib.el parts of David Edmondson's patch (see
id:1325006003-27152-1-git-send-email-...@dme.org)
---
 emacs/notmuch-lib.el |   18 ++
 emacs/notmuch.el |   15 +--
 2 files changed, 19 insertions(+), 14 deletions(-)

diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
index 6907a5f..c8a9351 100644
--- a/emacs/notmuch-lib.el
+++ b/emacs/notmuch-lib.el
@@ -148,6 +148,24 @@ the user hasn't set this variable with the old or new 
value.
   Return a query that matches the message with id ID.
   (concat id:\ (replace-regexp-in-string \ \\ id t t) \))
 
+(defun notmuch-color-line (start end line-tag-list spec)
+  Colorize a line based on tags.
+  ;; Create the overlay only if the message has tags which match one
+  ;; of those specified in `spec'.
+  (let (overlay)
+(mapc (lambda (elem)
+   (let ((tag (car elem))
+ (attributes (cdr elem)))
+ (when (member tag line-tag-list)
+   (when (not overlay)
+ (setq overlay (make-overlay start end))
+ (overlay-put overlay 'priority 5))
+   ;; Merge the specified properties with any already
+   ;; applied from an earlier match.
+   (overlay-put overlay 'face
+(append (overlay-get overlay 'face) attributes)
+ spec)))
+
 ;;
 
 (defun notmuch-common-do-stash (text)
diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index c6236db..d5f40e2 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -612,20 +612,7 @@ foreground and blue background.
 
 (defun notmuch-search-color-line (start end line-tag-list)
   Colorize lines in `notmuch-show' based on tags.
-  ;; Create the overlay only if the message has tags which match one
-  ;; of those specified in `notmuch-search-line-faces'.
-  (let (overlay)
-(mapc (lambda (elem)
-   (let ((tag (car elem))
- (attributes (cdr elem)))
- (when (member tag line-tag-list)
-   (when (not overlay)
- (setq overlay (make-overlay start end)))
-   ;; Merge the specified properties with any already
-   ;; applied from an earlier match.
-   (overlay-put overlay 'face
-(append (overlay-get overlay 'face) attributes)
- notmuch-search-line-faces)))
+  (notmuch-color-line start end line-tag-list notmuch-search-line-faces))
 
 (defun notmuch-search-author-propertize (authors)
   Split `authors' into matching and non-matching authors and
-- 
1.7.9.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

[Patch v2 2/3] emacs: Add `notmuch-show-line-faces' and apply it.

[Mark Walters]

Similar to `notmuch-search-line-faces', `notmuch-show-line-faces'
allows the header line in `notmuch-show-mode' buffers to be coloured
according to the tags of the message. This is just a rebased version of
the  emacs/notmuch-show.el of David Edmondson's patch
id:1325006003-27152-1-git-send-email-...@dme.org
---
 emacs/notmuch-show.el |   33 +
 1 files changed, 29 insertions(+), 4 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 37f0ebb..bb7db6e 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -93,6 +93,24 @@ any given message.
   :group 'notmuch-show
   :group 'notmuch-hooks)
 
+(defcustom notmuch-show-line-faces nil
+  Tag to face mapping for header line highlighting in `notmuch-show-mode'.
+
+Here is an example of how to color search results based on tags.
+ (the following text would be placed in your ~/.emacs file):
+
+ (setq notmuch-search-line-faces '((\delete\ . (:foreground \red\
+ :background \blue\))
+   (\unread\ . (:foreground \green\
+
+The attributes defined for matching tags are merged, with later
+attributes overriding earlier. A message having both \delete\
+and \unread\ tags with the above settings would have a green
+foreground and blue background.
+  :type '(alist :key-type (string) :value-type (custom-face-edit))
+  :group 'notmuch-show
+  :group 'notmuch-faces)
+
 ;; Mostly useful for debugging.
 (defcustom notmuch-show-all-multipart/alternative-parts t
   Should all parts of multipart/alternative parts be shown?
@@ -411,7 +429,8 @@ unchanged ADDRESS if parsing fails.
 (defun notmuch-show-insert-headerline (headers date tags depth)
   Insert a notmuch style headerline based on HEADERS for a
 message at DEPTH in the current thread.
-  (let ((start (point)))
+  (let ((start (point))
+   overlay)
 (insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
depth))
(notmuch-show-clean-address (plist-get headers :From))
 (
@@ -420,7 +439,9 @@ message at DEPTH in the current thread.
(propertize (mapconcat 'identity tags  )
'face 'notmuch-tag-face)
)\n)
-(overlay-put (make-overlay start (point)) 'face 
'notmuch-message-summary-face)))
+(setq overlay (make-overlay start (point)))
+(overlay-put overlay 'face 'notmuch-message-summary-face)
+(overlay-put overlay 'priority 2)))
 
 (defun notmuch-show-insert-header (header header-value)
   Insert a single header.
@@ -852,7 +873,8 @@ current buffer, if possible.
 body-start body-end
 (headers-invis-spec (notmuch-show-make-symbol header))
 (message-invis-spec (notmuch-show-make-symbol message))
-(bare-subject (notmuch-show-strip-re (plist-get headers :Subject
+(bare-subject (notmuch-show-strip-re (plist-get headers :Subject)))
+(tags (plist-get msg :tags)))
 
 ;; Set `buffer-invisibility-spec' to `nil' (a list), otherwise
 ;; removing items from `buffer-invisibility-spec' (which is what
@@ -877,10 +899,13 @@ current buffer, if possible.
(plist-get msg :date_relative)
  nil)
(plist-get headers :Date))
-   (plist-get msg :tags) depth)
+   tags depth)
 
 (setq content-start (point-marker))
 
+;; Colour the header line according to the tags of the message.
+(notmuch-color-line message-start content-start tags 
notmuch-show-line-faces)
+
 (plist-put msg :headers-invis-spec headers-invis-spec)
 (plist-put msg :message-invis-spec message-invis-spec)
 
-- 
1.7.9.1

___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Austin Clements]

I haven't really looked at this series yet, but I do have a quick
high-level question.  Why use separate customization variables for the
colors in search and show mode?  Wouldn't it make more sense to set
the colors just once and use them in both modes?

BTW, I like how this clearly distinguishes tags and flags.  I wonder
if we could transition to flags for some information that's current
shoe-horned into tags but actually represents immutable information
about a message (attachment, signed, and encrypted or so).

My one concern is that there's a common tag called flagged, so this
might be overloading terminology.

Quoth Mark Walters on Apr 29 at 11:48 pm:
 This is a rebased (but otherwise unchanged) version of
 id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.
 
 It's probably too late for 0.13 but in case anyone would like to look
 at it this version applies cleanly to master so should be easier to
 test.
 
 The first two patches are basically David Edmondson's patch
 id:1325006003-27152-1-git-send-email-...@dme.org.
 
 Best wishes
 
 Mark
 
 
 Mark Walters (3):
   emacs: Move colour line from search to lib
   emacs: Add `notmuch-show-line-faces' and apply it.
   emacs: allow notmuch-show-line-faces to use flags for colouring
 
  emacs/notmuch-lib.el  |   18 ++
  emacs/notmuch-show.el |   44 
  emacs/notmuch.el  |   15 +--
  3 files changed, 59 insertions(+), 18 deletions(-)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 0/3] emacs: allow show to colour based on tags and flags

[Mark Walters]

On Mon, 30 Apr 2012, Austin Clements amdra...@mit.edu wrote:
 I haven't really looked at this series yet, but I do have a quick
 high-level question.  Why use separate customization variables for the
 colors in search and show mode?  Wouldn't it make more sense to set
 the colors just once and use them in both modes?

I think that their use is somewhat different since in show mode the
colour can be quite high contrast because mostly you only have a few
header lines (that may depend how much time you spend in
expanded/collapsed views); one example is that in show mode the header
line normally has a background colour (I think even without
customisation) whereas in search mode that would be weird as every line
would have it.

 BTW, I like how this clearly distinguishes tags and flags.  I wonder
 if we could transition to flags for some information that's current
 shoe-horned into tags but actually represents immutable information
 about a message (attachment, signed, and encrypted or so).

Yes some of those could make sense: I hadn't thought about them at
all. I think attachment is closer to a genuine tag as I frequently include
tag:attachment in my searched but I would guess that searching for
signed/encrypted is not as common (but I don't use either so could be wrong)

 My one concern is that there's a common tag called flagged, so this
 might be overloading terminology.

I hadn't thought of that: I agree but don't have a good suggestion for
avoiding it. 

Best wishes

Mark



 Quoth Mark Walters on Apr 29 at 11:48 pm:
 This is a rebased (but otherwise unchanged) version of
 id:1334431301-27303-1-git-send-email-markwalters1...@gmail.com.
 
 It's probably too late for 0.13 but in case anyone would like to look
 at it this version applies cleanly to master so should be easier to
 test.
 
 The first two patches are basically David Edmondson's patch
 id:1325006003-27152-1-git-send-email-...@dme.org.
 
 Best wishes
 
 Mark
 
 
 Mark Walters (3):
   emacs: Move colour line from search to lib
   emacs: Add `notmuch-show-line-faces' and apply it.
   emacs: allow notmuch-show-line-faces to use flags for colouring
 
  emacs/notmuch-lib.el  |   18 ++
  emacs/notmuch-show.el |   44 
  emacs/notmuch.el  |   15 +--
  3 files changed, 59 insertions(+), 18 deletions(-)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch

Re: [Patch v2 3/3] emacs: allow notmuch-show-line-faces to use flags for colouring

[Tomi Ollila]

On Mon, Apr 30 2012, Mark Walters markwalters1...@gmail.com wrote:

[ ... ]
 ---
  emacs/notmuch-show.el |   21 -
  1 files changed, 16 insertions(+), 5 deletions(-)

[ ... ]

 - (setq notmuch-search-line-faces '((\delete\ . (:foreground \red\
 + (setq notmuch-search-line-faces '((\tag:delete\ . (:foreground \red\
 :background \blue\))
 -   (\unread\ . (:foreground \green\
 +   (\tag:unread\ . (:foreground \green\))
 +   (\flag:excluded\ . (:background 
 \grey\

Quick note -- delete is to be changed to deleted (in examples, too :)


Tomi
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch