[PATCH] emacs: notmuch-search: fix faces

[Michal Nazarewicz]

From: Michal Nazarewicz 

For some reason the faces do not get applied when 'face property is
used, but they work correctly with 'font-lock-face property.  This
commit changes notmuch-search to use the latter.
---
 emacs/notmuch.el |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 7b61e9b..44cbe28 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -692,10 +692,10 @@ propertize appropriately. If no boundary between authors 
and
 non-authors is found, assume that all of the authors match."
   (if (string-match "\\(.*\\)|\\(.*\\)" authors)
   (concat (propertize (concat (match-string 1 authors) ",")
- 'face 'notmuch-search-matching-authors)
+ 'font-lock-face 'notmuch-search-matching-authors)
  (propertize (match-string 2 authors)
- 'face 'notmuch-search-non-matching-authors))
-(propertize authors 'face 'notmuch-search-matching-authors)))
+ 'font-lock-face 'notmuch-search-non-matching-authors))
+(propertize authors 'font-lock-face 'notmuch-search-matching-authors)))

 (defun notmuch-search-insert-authors (format-string authors)
   ;; Save the match data to avoid interfering with
@@ -741,11 +741,14 @@ non-authors is found, assume that all of the authors 
match."
  (setq visible-string (notmuch-search-author-propertize visible-string)
;; The invisible string must contain only non-matching
;; authors, as the visible-string contains both.
-   invisible-string (propertize invisible-string
-'face 
'notmuch-search-non-matching-authors))
+   invisible-string
+   (propertize invisible-string
+   'font-lock-face
+   'notmuch-search-non-matching-authors))
;; The visible string contains only matching authors.
(setq visible-string (propertize visible-string
-'face 'notmuch-search-matching-authors)
+'font-lock-face
+'notmuch-search-matching-authors)
  ;; The invisible string may contain both matching and
  ;; non-matching authors.
  invisible-string (notmuch-search-author-propertize 
invisible-string)))
@@ -770,15 +773,15 @@ non-authors is found, assume that all of the authors 
match."
   (cond
((string-equal field "date")
 (insert (propertize (format format-string (plist-get result 
:date_relative))
-   'face 'notmuch-search-date)))
+   'font-lock-face 'notmuch-search-date)))
((string-equal field "count")
 (insert (propertize (format format-string
(format "[%s/%s]" (plist-get result :matched)
(plist-get result :total)))
-   'face 'notmuch-search-count)))
+   'font-lock-face 'notmuch-search-count)))
((string-equal field "subject")
 (insert (propertize (format format-string (plist-get result :subject))
-   'face 'notmuch-search-subject)))
+   'font-lock-face 'notmuch-search-subject)))

((string-equal field "authors")
 (notmuch-search-insert-authors format-string (plist-get result :authors)))
@@ -786,7 +789,7 @@ non-authors is found, assume that all of the authors match."
((string-equal field "tags")
 (let ((tags-str (mapconcat 'identity (plist-get result :tags) " ")))
   (insert (propertize (format format-string tags-str)
- 'face 'notmuch-tag-face))
+ 'font-lock-face 'notmuch-tag-face))

 (defun notmuch-search-show-result (result  pos)
   "Insert RESULT at POS or the end of the buffer if POS is null."
-- 
1.7.7.3

Errors after upgrade to 0.14

[Bart Bunting]

Ok perhaps this is more helpfull?

Debugger entered--Lisp error: (wrong-type-argument number-or-marker-p nil)
  notmuch-search-show-result("tags")
  byte-code("\304\305\"\203\306
!\307=\203\310\202Q\303\202Q\304\311\"\203D\312
!\304\313\"\2030\310\202@\304\314\"\203<\315\202@\316!\210)\202Q\304\317\"\203Q\320
 !\210\310\304\207" [notmuch-search-process-state notmuch-search-json-parser 
done result memql (begin) notmuch-json-begin-compound retry t (result) 
notmuch-json-read (retry) (end) end notmuch-search-show-result (end) 
notmuch-json-eof] 3)
  notmuch-search-process-filter(# ", \"tags\": []},\nA 
Xapian exception occurred performing query: The revision being read has been 
discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a59\n{\"thread\": 
\"0001fd19\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a57\n{\"thread\": 
\"00020a59\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": \"\", \"subject\": \"\", \"tags\": 
[]},\nA Xapian exception occurred performing query: The revision being read has 
been discarded - you should call Xapian::Database::reopen() and retry the 
operation\nQuery string was: thread:00020a57\n{\"thread\": 
\"00020a57\", \"timestamp\": 0, \"date_relative\": \"1970-01-01\", 
\"matched\": 0, \"total\": 0, \"authors\": ")
  recursive-edit()
  debug(error (error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  error("A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked")
  notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:00022288")
  apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
"thread:00022288"))
  notmuch-tag("thread:00022288" ("-inbox"))
  notmuch-search-tag-region(202 202 ("-inbox"))
  notmuch-search-tag(("-inbox"))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)
  recursive-edit()
  debug(error (error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")


Kind regards

Bart

Errors after upgrade to 0.14

[Bart Bunting]

Austin,

I agree, it appears to be the normal locking issue.
That poses a problem but one I'm used to.

I was doing an archive when I hit the other error as well.

I just got a debug traceback when entering the inbox from the hello
screen.  Unfortunately it locked up my entire emacs and had to kill the
process.

I'll keep trying until I get something more helpfull.

Cheers
Bart




Austin Clements  writes:

> This looks like a different error from the one in your original email.
> Was the original error also triggered by hitting 'a'?
>
> This error is definitely from simultaneous access to the database and
> is expected.  But this has been a problem since the dawn of notmuch
> and shouldn't have started just with 0.14 (unless we did something to
> make it worse?).  I do have some experimental patches that fix the
> database locking issues if it's turning out to be a serious problem
> for you, but the fix introduces its own issues.
>
> Quoth Bart Bunting on Aug 23 at 11:21 am:
>> Hi Austin,
>> 
>> I applied the patch and this error was from after that.
>> 
>> The way it was triggered was by hitting 'a' to archive a message in the
>> search view.
>> 
>> From what I can tell it's just the xapian error and there is nothing
>> about json.  Hope it means more to you.
>> 
>> Debugger entered--Lisp error: (error "A Xapian exception occurred opening 
>> database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: 
>> already locked")
>>   ad-Orig-signal(error ("A Xapian exception occurred opening database: 
>> Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
>> locked"))
>>   signal(error ("A Xapian exception occurred opening database: Unable to get 
>> write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
>>   ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
>> write lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   apply(ad-Orig-error "A Xapian exception occurred opening database: Unable 
>> to get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   error("A Xapian exception occurred opening database: Unable to get write 
>> lock on /Users/bart/mail/.notmuch/xapian: already locked")
>>   notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:000225c8")
>>   apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
>> "thread:000225c8"))
>>   notmuch-tag("thread:000225c8" ("-inbox"))
>>   notmuch-search-tag-region(800 800 ("-inbox"))
>>   notmuch-search-tag(("-inbox"))
>>   ad-Orig-notmuch-search-archive-thread()
>>   notmuch-search-archive-thread()
>>   call-interactively(notmuch-search-archive-thread nil nil)
>> 
>> 
>> Kind regards
>> 
>> Austin Clements  writes:
>> 
>> > Quoth myself on Aug 22 at  8:41 pm:
>> >> Quoth Bart Bunting on Aug 23 at  9:36 am:
>> >> > Good morning,
>> >> > 
>> >> > After upgrading to notmuch 014 I am seeing the following messages appear
>> >> > in the messages buffer.
>> >> > 
>> >> > error in process filter: byte-code: Wrong type argument: 
>> >> > number-or-marker-p, nil
>> >> > error in process filter: Wrong type argument: number-or-marker-p, nil
>> >> > 
>> >> > I am also getting a repeating message in the minibuffer (I think) which
>> >> > says something like "json read tail error".  Sorry that I am not more
>> >> > specific as I use emacspeak and this message appears to repeat many
>> >> > times interupting speech so I am not 100% sure of what it exactly says.
>> >> 
>> >> This is probably "json-readtable-error", which is, unfortunately,
>> >> about the most generic error the JSON parser can give.
>> >> 
>> >> > My gut feeling is that it is happening when notmuch is updating the
>> >> > database or something.
>> >> > 
>> >> > Is this expected behaviour?  It is particularly annoying for me as it
>> >> > sends the speech synth crazy and crashes it for a period of about 30
>> >> > seconds.
>> >> > 
>> >> > If it is expected then I will try and find a way to prevent emacspeak
>> >> > from trying to read it.
>> >> 
>> >> This is definitely not expected behavior.  Does this happen when
>> >> you're searching for messages or when you're viewing a thread?  Can
>> >> you give any more details on what you're doing when you get this
>> >> error?
>> >> 
>> >> Try doing M-x toggle-debug-on-error and then triggering the error.
>> >> Hopefully Emacs will give you a buffer with a backtrace that will give
>> >> us a better idea of where this is happening.
>> >
>> > Actually, I might know what's going on here.  Based on your suspicion
>> > about notmuch updating the database and assuming that this happens in
>> > the search buffer, I think the parser error recovery code is leaving
>> > the parser in a slightly invalid state, which causes the next
>> > invocation to think it can consume more data when there is no more
>> > data to consume.  I would expect that to give at most one readtable
>> > error, but maybe there's something I'm overlooking.
>> >
>> > Could you try 

Errors after upgrade to 0.14

[Bart Bunting]

Hi Austin,

I applied the patch and this error was from after that.

The way it was triggered was by hitting 'a' to archive a message in the
search view.

>From what I can tell it's just the xapian error and there is nothing
about json.  Hope it means more to you.

Debugger entered--Lisp error: (error "A Xapian exception occurred opening 
database: Unable to get write lock on /Users/bart/mail/.notmuch/xapian: already 
locked")
  ad-Orig-signal(error ("A Xapian exception occurred opening database: Unable 
to get write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  signal(error ("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked"))
  ad-Orig-error("A Xapian exception occurred opening database: Unable to get 
write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  apply(ad-Orig-error "A Xapian exception occurred opening database: Unable to 
get write lock on /Users/bart/mail/.notmuch/xapian: already locked")
  error("A Xapian exception occurred opening database: Unable to get write lock 
on /Users/bart/mail/.notmuch/xapian: already locked")
  notmuch-call-notmuch-process("tag" "-inbox" "--" "thread:000225c8")
  apply(notmuch-call-notmuch-process "tag" ("-inbox" "--" 
"thread:000225c8"))
  notmuch-tag("thread:000225c8" ("-inbox"))
  notmuch-search-tag-region(800 800 ("-inbox"))
  notmuch-search-tag(("-inbox"))
  ad-Orig-notmuch-search-archive-thread()
  notmuch-search-archive-thread()
  call-interactively(notmuch-search-archive-thread nil nil)


Kind regards

Austin Clements  writes:

> Quoth myself on Aug 22 at  8:41 pm:
>> Quoth Bart Bunting on Aug 23 at  9:36 am:
>> > Good morning,
>> > 
>> > After upgrading to notmuch 014 I am seeing the following messages appear
>> > in the messages buffer.
>> > 
>> > error in process filter: byte-code: Wrong type argument: 
>> > number-or-marker-p, nil
>> > error in process filter: Wrong type argument: number-or-marker-p, nil
>> > 
>> > I am also getting a repeating message in the minibuffer (I think) which
>> > says something like "json read tail error".  Sorry that I am not more
>> > specific as I use emacspeak and this message appears to repeat many
>> > times interupting speech so I am not 100% sure of what it exactly says.
>> 
>> This is probably "json-readtable-error", which is, unfortunately,
>> about the most generic error the JSON parser can give.
>> 
>> > My gut feeling is that it is happening when notmuch is updating the
>> > database or something.
>> > 
>> > Is this expected behaviour?  It is particularly annoying for me as it
>> > sends the speech synth crazy and crashes it for a period of about 30
>> > seconds.
>> > 
>> > If it is expected then I will try and find a way to prevent emacspeak
>> > from trying to read it.
>> 
>> This is definitely not expected behavior.  Does this happen when
>> you're searching for messages or when you're viewing a thread?  Can
>> you give any more details on what you're doing when you get this
>> error?
>> 
>> Try doing M-x toggle-debug-on-error and then triggering the error.
>> Hopefully Emacs will give you a buffer with a backtrace that will give
>> us a better idea of where this is happening.
>
> Actually, I might know what's going on here.  Based on your suspicion
> about notmuch updating the database and assuming that this happens in
> the search buffer, I think the parser error recovery code is leaving
> the parser in a slightly invalid state, which causes the next
> invocation to think it can consume more data when there is no more
> data to consume.  I would expect that to give at most one readtable
> error, but maybe there's something I'm overlooking.
>
> Could you try the following one line patch?
>
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index 900235b..a09c0f6 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -375,7 +375,7 @@ resynchronize after an error by moving point."
>  
>(if (eq (notmuch-json-next jp) 'value)
>;; We're already at a value
> -  nil
> +  (if (eobp) 'retry nil)
>  ;; Drive the state toward 'expect-value
>  (skip-chars-forward " \t\r\n")
>  (or (when (eobp) 'retry)
>
Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:   +61 2 8745 2811
Mbl:  0409 560 005

[PATCH 00/11] add recipients to search output

[Tomi Ollila]

On Mon, Aug 20 2012, Jameson Graef Rollins wrote:

> This series is an attempt to add thread recipients to the search
> output.
>
> My personal overall goal of this series is to support the handling of
> drafts in the emacs ui.  For drafts we want to see recipients, instead
> of authors, in the search output.  I can imagine other uses for this
> series as well, though.
>
> The first four patches generalize the author list handling in thread
> objects to handle any address list.  These patches could be applied
> regardless of if the rest of the series is accepted.
>
> After that we modify the thread constructor such that it can hold
> thread recipients as well.  Since there is overhead in retrieving
> thread recipients from the message files (recipients are not stored in
> the database) this is handled with a switch.
>
> Further patches add the new switch to the search CLI that adds thread
> recipients to the structured output formats.  I didn't modify the text
> output format, since there is no way to extend it.  I can imagine
> tweaking the text output such that the author field is instead
> replaced by the recipients (as is done for the emacs UI at the end of
> the series), but that's not done here.
>
> In the emacs UI, I add a new toggle function that will toggle display
> of thread authors or recipients in the 'authors' field of the search
> output.  It's unfortunate that this ambiguity in that field name
> remains, but I didn't know how to change that cleanly.  I'm working on
> some tests for the new emacs functionality that I'll include in the
> inevitable v2 of this series.

I did not read much of this introduction before browsing to the code, I
was about to comment whether attempt yo do less trivial tests are
to be done.

> The last patch is mostly just a tickle to suggest adding the
> recipients to the database.  It would make the --include-recipient
> searches much faster of course, but it might be overhead in the
> database that folks aren't interested in.

I got tickled... adding To (and Cc?!) to the database would also give
(future notmuch?) address completion more addresses to match for.

We should discuss whether to add other headers too? IIRC someone (Austin?)
mentioned that everything (except Received:) headers could be there ?

> As always, feedback, review, and comments are much appreciated.

Overall, the code looks good (to me).

> jamie.

Tomi

[PATCH] notmuch-show: add notmuch-show-mark-read-tags option

[Tomi Ollila]

On Tue, Aug 21 2012, Michal Nazarewicz wrote:

> From: Michal Nazarewicz 
>
> The `notmuch-show-mark-read-tags' lists tags that are to be applied when
> message is read.  By default, the only value is "-unread" which will remove
> the unread tag.  Among other uses, this variable can be used to stop
> notmuch-show from modifying tags when message is shown (by setting the
> variable to an empty list).
> ---

LGTM.

Tomi


>
>  I've sent this patch a while back but I think it got lost somehow so
>  resending.
>
>  emacs/notmuch-show.el |   12 ++--
>  1 files changed, 10 insertions(+), 2 deletions(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 82b5399..c9fd867 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -183,6 +183,13 @@ provided with an MLA argument nor `completing-read' 
> input."
>notmuch-show-stash-mlarchive-link-alist))
>:group 'notmuch-show)
>  
> +(defcustom notmuch-show-mark-read-tags '("-unread")
> +  "List of tags to apply when message is read, ie. shown in notmuch-show
> +buffer."
> +  :type '(repeat string)
> +  :group 'notmuch-show)
> +
> +
>  (defmacro with-current-notmuch-show-message ( body)
>"Evaluate body with current buffer set to the text of current message"
>`(save-excursion
> @@ -1383,8 +1390,9 @@ current thread."
>(notmuch-show-get-prop :headers-visible))
>  
>  (defun notmuch-show-mark-read ()
> -  "Mark the current message as read."
> -  (notmuch-show-tag-message "-unread"))
> +  "Apply `notmuch-show-mark-read-tags' to the message."
> +  (when notmuch-show-mark-read-tags
> +(apply 'notmuch-show-tag-message notmuch-show-mark-read-tags)))
>  
>  ;; Functions for getting attributes of several messages in the current
>  ;; thread.
> -- 
> 1.7.7.3
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch

Errors after upgrade to 0.14

[Bart Bunting]

Good morning,

After upgrading to notmuch 014 I am seeing the following messages appear
in the messages buffer.

error in process filter: byte-code: Wrong type argument: number-or-marker-p, nil
error in process filter: Wrong type argument: number-or-marker-p, nil

I am also getting a repeating message in the minibuffer (I think) which
says something like "json read tail error".  Sorry that I am not more
specific as I use emacspeak and this message appears to repeat many
times interupting speech so I am not 100% sure of what it exactly says.

My gut feeling is that it is happening when notmuch is updating the
database or something.

Is this expected behaviour?  It is particularly annoying for me as it
sends the speech synth crazy and crashes it for a period of about 30
seconds.

If it is expected then I will try and find a way to prevent emacspeak
from trying to read it.



Kind regards

Bart
-- 
Bart Bunting - Engineering Manager - URSYS
459-461 Parramatta Rd. Leichhardt  NSW  2040  Australia
Ph:   +61 2 8745 2811
Mbl:  0409 560 005

[PATCH 1/3] Add notmuch_database_close_compact

[Tomi Ollila]

On Thu, Aug 23 2012, Kim Minh Kaplan  wrote:

> Tomi Ollila?:
>
>> On Tue, Aug 21 2012, Ben Gamari wrote:
>>
>>> Eh? 1.2.6 is the first Xapian release to have Compactor exposed in the
>>> public API.
>>
>> Presuming that those variables are always numeric the comparison could be:
>>
>> if [ ${xapian_major_version} -gt 1 ] || 
>>[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -gt 2 ] || 
>>[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -eq 2 -a \
>>  ${xapian_subminor_version} -ge 6 ]; then
>>
>> (I could not figure out anything shorter and/or cleaner)
>
> Try:
>
> case "${xapian_version}" in
>  0.*|1.[01].*|1.2.[0-5]) ;;
>  *) ... ;;
> esac

That sure is shorter -- and splitting xapian_version
is not required...

.. also that would take care the (improbable?) case that
`${xapian_config} -- version` outputs something else than
#.#.# in the future.

On the other hand, the above doesn't catch junk, so maybe:

 case ${xapian_version} in
  0.*|1.[01].*|1.2.[0-5]) handle no case ;;  
  [1-9]*.[0-9]*.[0-9]*) handle yes case -- approximated test ;;
  *) failure ;;
 esac

(and we (approximately) expect #.#.#)

In any case, excellent idea !


> Kim Minh.

Thanks,

Tomi

[PATCH 1/3] Add notmuch_database_close_compact

[Kim Minh Kaplan]

Tomi Ollila?:

> On Tue, Aug 21 2012, Ben Gamari wrote:
>
>> Eh? 1.2.6 is the first Xapian release to have Compactor exposed in the
>> public API.
>
> Presuming that those variables are always numeric the comparison could be:
>
> if [ ${xapian_major_version} -gt 1 ] || 
>[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -gt 2 ] || 
>[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -eq 2 -a \
>  ${xapian_subminor_version} -ge 6 ]; then
>
> (I could not figure out anything shorter and/or cleaner)

Try:

case "${xapian_version}" in
 0.*|1.[01].*|1.2.[0-5]) ;;
 *) ... ;;
esac

Kim Minh.

Re: [PATCH 1/3] Add notmuch_database_close_compact

[Tomi Ollila]

On Thu, Aug 23 2012, Kim Minh Kaplan kimminh.kaplan+nom...@afnic.fr wrote:

 Tomi Ollila :

 On Tue, Aug 21 2012, Ben Gamari wrote:

 Eh? 1.2.6 is the first Xapian release to have Compactor exposed in the
 public API.

 Presuming that those variables are always numeric the comparison could be:

 if [ ${xapian_major_version} -gt 1 ] || 
[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -gt 2 ] || 
[ ${xapian_major_version} -eq 1 -a ${xapian_minor_version} -eq 2 -a \
  ${xapian_subminor_version} -ge 6 ]; then

 (I could not figure out anything shorter and/or cleaner)

 Try:

 case ${xapian_version} in
  0.*|1.[01].*|1.2.[0-5]) ;;
  *) ... ;;
 esac

That sure is shorter -- and splitting xapian_version
is not required...

.. also that would take care the (improbable?) case that
`${xapian_config} -- version` outputs something else than
#.#.# in the future.

On the other hand, the above doesn't catch junk, so maybe:

 case ${xapian_version} in
  0.*|1.[01].*|1.2.[0-5]) handle no case ;;  
  [1-9]*.[0-9]*.[0-9]*) handle yes case -- approximated test ;;
  *) failure ;;
 esac

(and we (approximately) expect #.#.#)

In any case, excellent idea !


 Kim Minh.

Thanks,

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

Re: [PATCH] notmuch-show: add notmuch-show-mark-read-tags option

[Tomi Ollila]

On Tue, Aug 21 2012, Michal Nazarewicz wrote:

 From: Michal Nazarewicz min...@mina86.com

 The `notmuch-show-mark-read-tags' lists tags that are to be applied when
 message is read.  By default, the only value is -unread which will remove
 the unread tag.  Among other uses, this variable can be used to stop
 notmuch-show from modifying tags when message is shown (by setting the
 variable to an empty list).
 ---

LGTM.

Tomi



  I've sent this patch a while back but I think it got lost somehow so
  resending.

  emacs/notmuch-show.el |   12 ++--
  1 files changed, 10 insertions(+), 2 deletions(-)

 diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
 index 82b5399..c9fd867 100644
 --- a/emacs/notmuch-show.el
 +++ b/emacs/notmuch-show.el
 @@ -183,6 +183,13 @@ provided with an MLA argument nor `completing-read' 
 input.
notmuch-show-stash-mlarchive-link-alist))
:group 'notmuch-show)
  
 +(defcustom notmuch-show-mark-read-tags '(-unread)
 +  List of tags to apply when message is read, ie. shown in notmuch-show
 +buffer.
 +  :type '(repeat string)
 +  :group 'notmuch-show)
 +
 +
  (defmacro with-current-notmuch-show-message (rest body)
Evaluate body with current buffer set to the text of current message
`(save-excursion
 @@ -1383,8 +1390,9 @@ current thread.
(notmuch-show-get-prop :headers-visible))
  
  (defun notmuch-show-mark-read ()
 -  Mark the current message as read.
 -  (notmuch-show-tag-message -unread))
 +  Apply `notmuch-show-mark-read-tags' to the message.
 +  (when notmuch-show-mark-read-tags
 +(apply 'notmuch-show-tag-message notmuch-show-mark-read-tags)))
  
  ;; Functions for getting attributes of several messages in the current
  ;; thread.
 -- 
 1.7.7.3

 ___
 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 00/11] add recipients to search output

[Tomi Ollila]

On Mon, Aug 20 2012, Jameson Graef Rollins wrote:

 This series is an attempt to add thread recipients to the search
 output.

 My personal overall goal of this series is to support the handling of
 drafts in the emacs ui.  For drafts we want to see recipients, instead
 of authors, in the search output.  I can imagine other uses for this
 series as well, though.

 The first four patches generalize the author list handling in thread
 objects to handle any address list.  These patches could be applied
 regardless of if the rest of the series is accepted.

 After that we modify the thread constructor such that it can hold
 thread recipients as well.  Since there is overhead in retrieving
 thread recipients from the message files (recipients are not stored in
 the database) this is handled with a switch.

 Further patches add the new switch to the search CLI that adds thread
 recipients to the structured output formats.  I didn't modify the text
 output format, since there is no way to extend it.  I can imagine
 tweaking the text output such that the author field is instead
 replaced by the recipients (as is done for the emacs UI at the end of
 the series), but that's not done here.

 In the emacs UI, I add a new toggle function that will toggle display
 of thread authors or recipients in the 'authors' field of the search
 output.  It's unfortunate that this ambiguity in that field name
 remains, but I didn't know how to change that cleanly.  I'm working on
 some tests for the new emacs functionality that I'll include in the
 inevitable v2 of this series.

I did not read much of this introduction before browsing to the code, I
was about to comment whether attempt yo do less trivial tests are
to be done.

 The last patch is mostly just a tickle to suggest adding the
 recipients to the database.  It would make the --include-recipient
 searches much faster of course, but it might be overhead in the
 database that folks aren't interested in.

I got tickled... adding To (and Cc?!) to the database would also give
(future notmuch?) address completion more addresses to match for.

We should discuss whether to add other headers too? IIRC someone (Austin?)
mentioned that everything (except Received:) headers could be there ?

 As always, feedback, review, and comments are much appreciated.

Overall, the code looks good (to me).

 jamie.

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

[PATCH] emacs: notmuch-search: fix faces

[Michal Nazarewicz]

From: Michal Nazarewicz min...@mina86.com

For some reason the faces do not get applied when 'face property is
used, but they work correctly with 'font-lock-face property.  This
commit changes notmuch-search to use the latter.
---
 emacs/notmuch.el |   23 +--
 1 files changed, 13 insertions(+), 10 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 7b61e9b..44cbe28 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -692,10 +692,10 @@ propertize appropriately. If no boundary between authors 
and
 non-authors is found, assume that all of the authors match.
   (if (string-match \\(.*\\)|\\(.*\\) authors)
   (concat (propertize (concat (match-string 1 authors) ,)
- 'face 'notmuch-search-matching-authors)
+ 'font-lock-face 'notmuch-search-matching-authors)
  (propertize (match-string 2 authors)
- 'face 'notmuch-search-non-matching-authors))
-(propertize authors 'face 'notmuch-search-matching-authors)))
+ 'font-lock-face 'notmuch-search-non-matching-authors))
+(propertize authors 'font-lock-face 'notmuch-search-matching-authors)))
 
 (defun notmuch-search-insert-authors (format-string authors)
   ;; Save the match data to avoid interfering with
@@ -741,11 +741,14 @@ non-authors is found, assume that all of the authors 
match.
  (setq visible-string (notmuch-search-author-propertize visible-string)
;; The invisible string must contain only non-matching
;; authors, as the visible-string contains both.
-   invisible-string (propertize invisible-string
-'face 
'notmuch-search-non-matching-authors))
+   invisible-string
+   (propertize invisible-string
+   'font-lock-face
+   'notmuch-search-non-matching-authors))
;; The visible string contains only matching authors.
(setq visible-string (propertize visible-string
-'face 'notmuch-search-matching-authors)
+'font-lock-face
+'notmuch-search-matching-authors)
  ;; The invisible string may contain both matching and
  ;; non-matching authors.
  invisible-string (notmuch-search-author-propertize 
invisible-string)))
@@ -770,15 +773,15 @@ non-authors is found, assume that all of the authors 
match.
   (cond
((string-equal field date)
 (insert (propertize (format format-string (plist-get result 
:date_relative))
-   'face 'notmuch-search-date)))
+   'font-lock-face 'notmuch-search-date)))
((string-equal field count)
 (insert (propertize (format format-string
(format [%s/%s] (plist-get result :matched)
(plist-get result :total)))
-   'face 'notmuch-search-count)))
+   'font-lock-face 'notmuch-search-count)))
((string-equal field subject)
 (insert (propertize (format format-string (plist-get result :subject))
-   'face 'notmuch-search-subject)))
+   'font-lock-face 'notmuch-search-subject)))
 
((string-equal field authors)
 (notmuch-search-insert-authors format-string (plist-get result :authors)))
@@ -786,7 +789,7 @@ non-authors is found, assume that all of the authors match.
((string-equal field tags)
 (let ((tags-str (mapconcat 'identity (plist-get result :tags)  )))
   (insert (propertize (format format-string tags-str)
- 'face 'notmuch-tag-face))
+ 'font-lock-face 'notmuch-tag-face))
 
 (defun notmuch-search-show-result (result optional pos)
   Insert RESULT at POS or the end of the buffer if POS is null.
-- 
1.7.7.3

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