[PATCH v2] emacs: jump: sort-order bugfix

2014-09-02 Thread Mark Walters
default-value needs its argument to be quoted.

Slightly strangely default-value of 't or nil is 't or nil
respectively so the code

(default-value notmuch-search-oldest-first)

just gives the current value of notmuch-search-oldest-first rather
than intended default-value of this variable.

The symptom is that if you are in a search buffer and use notmuch jump
to run a saved search which does not have an explicitly set sort order
then the sort order of the saved-search is inherited from the current
search buffer rather than being the default search order.

Thanks to Jani for finding the bug.
---

This time with a fuller commit message.

(Part of the reason I did not send more before is I had not checked
what the exact outcome of the buggy code was: it was obvious what the
code was intended to do, and that with the extra quote it
would do what it was intended to do.)

Best wishes

Mark







 emacs/notmuch-jump.el |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
index 5eb0949..0193f8c 100644
--- a/emacs/notmuch-jump.el
+++ b/emacs/notmuch-jump.el
@@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
 (case (plist-get saved-search :sort-order)
   (newest-first nil)
   (oldest-first t)
-  (otherwise (default-value notmuch-search-oldest-first)
+  (otherwise (default-value 'notmuch-search-oldest-first)
(push (list key name
`(lambda () (notmuch-search ',query ',oldest-first)))
  action-map)
-- 
1.7.10.4



[PATCH v2] emacs: jump: sort-order bugfix

2014-09-02 Thread Austin Clements
LGTM.

Quoth Mark Walters on Sep 02 at  7:56 pm:
> default-value needs its argument to be quoted.
> 
> Slightly strangely default-value of 't or nil is 't or nil
> respectively so the code
> 
> (default-value notmuch-search-oldest-first)
> 
> just gives the current value of notmuch-search-oldest-first rather
> than intended default-value of this variable.
> 
> The symptom is that if you are in a search buffer and use notmuch jump
> to run a saved search which does not have an explicitly set sort order
> then the sort order of the saved-search is inherited from the current
> search buffer rather than being the default search order.
> 
> Thanks to Jani for finding the bug.
> ---
> 
> This time with a fuller commit message.
> 
> (Part of the reason I did not send more before is I had not checked
> what the exact outcome of the buggy code was: it was obvious what the
> code was intended to do, and that with the extra quote it
> would do what it was intended to do.)
> 
> Best wishes
> 
> Mark
> 
> 
> 
> 
> 
> 
> 
>  emacs/notmuch-jump.el |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
> index 5eb0949..0193f8c 100644
> --- a/emacs/notmuch-jump.el
> +++ b/emacs/notmuch-jump.el
> @@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
>(case (plist-get saved-search :sort-order)
>  (newest-first nil)
>  (oldest-first t)
> -(otherwise (default-value notmuch-search-oldest-first)
> +(otherwise (default-value 'notmuch-search-oldest-first)
>   (push (list key name
>   `(lambda () (notmuch-search ',query ',oldest-first)))
> action-map)


sending email using different server for different 'From:' field

2014-09-02 Thread David Belohrad
Dear All,

I have my emacs/notmuch installation setup such, that I send the emails
usually directly using local exim4 installation. For particular 'From:'
field however I need to use my work server. Nowadays I do that
manually. Hence if I write an email using my work address, I manually
call a function switching the exim4 to work server. when the mail is
sent, i manually set it back to exim.

could that scenario be somehow fitted automatically, so when I overwrite
the default 'From:' address (by hand. is it possible to do some
automatic cycling?) to work address, so that message sender in emacs
would automatically use work exchange server to deliver the mail?


many thanks


david




[PATCH] emacs: jump: sort-order bugfix

2014-09-02 Thread Mark Walters
default-value needs its argument to be quoted.
---

Slightly strangely default-value of 't or nil is 't or nil
respectively so the code didn't give an error but just did the wrong
thing.

Thanks to Jani for finding the bug.

Best wishes

Mark

 emacs/notmuch-jump.el |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
index 5eb0949..0193f8c 100644
--- a/emacs/notmuch-jump.el
+++ b/emacs/notmuch-jump.el
@@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
 (case (plist-get saved-search :sort-order)
   (newest-first nil)
   (oldest-first t)
-  (otherwise (default-value notmuch-search-oldest-first)
+  (otherwise (default-value 'notmuch-search-oldest-first)
(push (list key name
`(lambda () (notmuch-search ',query ',oldest-first)))
  action-map)
-- 
1.7.10.4



[Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail

2014-09-02 Thread Tomi Ollila
On Tue, Sep 02 2014, Daniel Kahn Gillmor  wrote:

> On 08/30/2014 03:37 AM, Jani Nikula wrote:
>> I'm inclined to think this is a bug in message-mode. 
>
> I agree it's a bug in message-mode, not in notmuch itself.

I think it might be here:

http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/gnus/mml.el#L258

(it takes time to load, please wait...)

If cond does not match, then don't fail...

Tomi

>
>> As a workaround of sorts, I'd suggest not messing with the #secure tag
>> manually. Instead, you can use mml-secure-message-sign and
>> mml-secure-message-sign-encrypt to change the mode.
>
> the keybindings for those are usually:
>
>  C-c RET s p
>  C-c RET c p
>
> hth,
>
>   --dkg
>
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] doc: 'rm -f' potential doxygen temporary output file

2014-09-02 Thread David Bremner
Tomi Ollila  writes:

> Some (older) Doxygen versions do not create such a temporary file.
>
> ---

pushed.

d


[PATCH] lib: Fix endless upgrade problem

2014-09-02 Thread Tomi Ollila
On Tue, Sep 02 2014, Austin Clements  wrote:

> 48db8c8 introduced a disagreement between when
> notmuch_database_needs_upgrade returned TRUE and when
> notmuch_database_upgrade actually performed an upgrade.  As a result,
> if a database had a version less than 3, but no new features were
> required, notmuch new would call notmuch_database_upgrade to perform
> an upgrade, but notmuch_database_upgrade would return immediately
> without updating the database version.  Hence, the next notmuch new
> would do the same, and so on.
>
> Fix this by ensuring that the upgrade-required logic is identical
> between the two.

LGTM

Tomi

> ---
>  lib/database.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/lib/database.cc b/lib/database.cc
> index 5116188..a3a7cd3 100644
> --- a/lib/database.cc
> +++ b/lib/database.cc
> @@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>  target_features = notmuch->features | NOTMUCH_FEATURES_CURRENT;
>  new_features = NOTMUCH_FEATURES_CURRENT & ~notmuch->features;
>  
> -if (! new_features)
> +if (! notmuch_database_needs_upgrade (notmuch))
>   return NOTMUCH_STATUS_SUCCESS;
>  
>  if (progress_notify) {
> -- 
> 2.0.0
>
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


sending email using different server for different 'From:' field

2014-09-02 Thread Keith Amidon
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
> could that scenario be somehow fitted automatically, so when I overwrite
> the default 'From:' address (by hand. is it possible to do some
> automatic cycling?) to work address, so that message sender in emacs
> would automatically use work exchange server to deliver the mail?

I think this is more of a message-mode question than a notmuch question.
I use something very similar to code attached below, which is rather
brute-force, but does the job for me.

 --- Keith

-

(defun kea/send-mail-with-x ()
  (interactive)
  (setq smtpmail-smtp-server "smtp.x.com"
smtpmail-smtp-service 587
smtpmail-local-domain "x.com"
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/send-mail-with-y ()
  (interactive)
  (setq smtpmail-smtp-server "email.y.com"
smtpmail-smtp-service 587
smtpmail-local-domain "y.com"
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/message-select-mail-dest ()
  (cond ((string-match ""
   (message-field-value "From"))
 (kea/send-mail-with-x))
(t
 (kea/send-mail-with-y

(kea/send-mail-with-y)
(add-hook 'message-send-hook 'kea/message-select-mail-dest)





[PATCH] lib: Fix endless upgrade problem

2014-09-02 Thread Mark Walters

On Tue, 02 Sep 2014, Tomi Ollila  wrote:
> On Tue, Sep 02 2014, Austin Clements  wrote:
>
>> 48db8c8 introduced a disagreement between when
>> notmuch_database_needs_upgrade returned TRUE and when
>> notmuch_database_upgrade actually performed an upgrade.  As a result,
>> if a database had a version less than 3, but no new features were
>> required, notmuch new would call notmuch_database_upgrade to perform
>> an upgrade, but notmuch_database_upgrade would return immediately
>> without updating the database version.  Hence, the next notmuch new
>> would do the same, and so on.
>>
>> Fix this by ensuring that the upgrade-required logic is identical
>> between the two.
>
> LGTM

and me +1

Mark


>
> Tomi
>
>> ---
>>  lib/database.cc | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/lib/database.cc b/lib/database.cc
>> index 5116188..a3a7cd3 100644
>> --- a/lib/database.cc
>> +++ b/lib/database.cc
>> @@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
>>  target_features = notmuch->features | NOTMUCH_FEATURES_CURRENT;
>>  new_features = NOTMUCH_FEATURES_CURRENT & ~notmuch->features;
>>  
>> -if (! new_features)
>> +if (! notmuch_database_needs_upgrade (notmuch))
>>  return NOTMUCH_STATUS_SUCCESS;
>>  
>>  if (progress_notify) {
>> -- 
>> 2.0.0
>>
>> ___
>> notmuch mailing list
>> notmuch at notmuchmail.org
>> http://notmuchmail.org/mailman/listinfo/notmuch
> ___
> notmuch mailing list
> notmuch at notmuchmail.org
> http://notmuchmail.org/mailman/listinfo/notmuch


[Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail

2014-09-02 Thread Daniel Kahn Gillmor
On 08/30/2014 03:37 AM, Jani Nikula wrote:
> I'm inclined to think this is a bug in message-mode. 

I agree it's a bug in message-mode, not in notmuch itself.

> As a workaround of sorts, I'd suggest not messing with the #secure tag
> manually. Instead, you can use mml-secure-message-sign and
> mml-secure-message-sign-encrypt to change the mode.

the keybindings for those are usually:

 C-c RET s p
 C-c RET c p

hth,

--dkg


-- next part --
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 949 bytes
Desc: OpenPGP digital signature
URL: 
<http://notmuchmail.org/pipermail/notmuch/attachments/20140902/f0656afa/attachment.pgp>


[PATCH] lib: Fix endless upgrade problem

2014-09-02 Thread David Bremner
Austin Clements  writes:

> 48db8c8 introduced a disagreement between when
> notmuch_database_needs_upgrade returned TRUE and when
> notmuch_database_upgrade actually performed an upgrade.  As a result,
> if a database had a version less than 3, but no new features were
> required, notmuch new would call notmuch_database_upgrade to perform
> an upgrade, but notmuch_database_upgrade would return immediately
> without updating the database version.  Hence, the next notmuch new
> would do the same, and so on.
>

Thanks for the quick fix.

pushed,

d


Re: [PATCH] lib: Fix endless upgrade problem

2014-09-02 Thread Mark Walters

On Tue, 02 Sep 2014, Tomi Ollila tomi.oll...@iki.fi wrote:
 On Tue, Sep 02 2014, Austin Clements amdra...@mit.edu wrote:

 48db8c8 introduced a disagreement between when
 notmuch_database_needs_upgrade returned TRUE and when
 notmuch_database_upgrade actually performed an upgrade.  As a result,
 if a database had a version less than 3, but no new features were
 required, notmuch new would call notmuch_database_upgrade to perform
 an upgrade, but notmuch_database_upgrade would return immediately
 without updating the database version.  Hence, the next notmuch new
 would do the same, and so on.

 Fix this by ensuring that the upgrade-required logic is identical
 between the two.

 LGTM

and me +1

Mark



 Tomi

 ---
  lib/database.cc | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/lib/database.cc b/lib/database.cc
 index 5116188..a3a7cd3 100644
 --- a/lib/database.cc
 +++ b/lib/database.cc
 @@ -1222,7 +1222,7 @@ notmuch_database_upgrade (notmuch_database_t *notmuch,
  target_features = notmuch-features | NOTMUCH_FEATURES_CURRENT;
  new_features = NOTMUCH_FEATURES_CURRENT  ~notmuch-features;
  
 -if (! new_features)
 +if (! notmuch_database_needs_upgrade (notmuch))
  return NOTMUCH_STATUS_SUCCESS;
  
  if (progress_notify) {
 -- 
 2.0.0

 ___
 notmuch mailing list
 notmuch@notmuchmail.org
 http://notmuchmail.org/mailman/listinfo/notmuch
 ___
 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] lib: Fix endless upgrade problem

2014-09-02 Thread David Bremner
Austin Clements amdra...@mit.edu writes:

 48db8c8 introduced a disagreement between when
 notmuch_database_needs_upgrade returned TRUE and when
 notmuch_database_upgrade actually performed an upgrade.  As a result,
 if a database had a version less than 3, but no new features were
 required, notmuch new would call notmuch_database_upgrade to perform
 an upgrade, but notmuch_database_upgrade would return immediately
 without updating the database version.  Hence, the next notmuch new
 would do the same, and so on.


Thanks for the quick fix.

pushed,

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


Re: [Vagrant Cascadian] Bug#759646: notmuch-emacs: switching mode= to invalid value sends unencrypted mail

2014-09-02 Thread Tomi Ollila
On Tue, Sep 02 2014, Daniel Kahn Gillmor d...@fifthhorseman.net wrote:

 On 08/30/2014 03:37 AM, Jani Nikula wrote:
 I'm inclined to think this is a bug in message-mode. 

 I agree it's a bug in message-mode, not in notmuch itself.

I think it might be here:

http://bzr.savannah.gnu.org/lh/emacs/emacs-24/annotate/head:/lisp/gnus/mml.el#L258

(it takes time to load, please wait...)

If cond does not match, then don't fail...

Tomi


 As a workaround of sorts, I'd suggest not messing with the #secure tag
 manually. Instead, you can use mml-secure-message-sign and
 mml-secure-message-sign-encrypt to change the mode.

 the keybindings for those are usually:

  C-c RET s p
  C-c RET c p

 hth,

   --dkg


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


sending email using different server for different 'From:' field

2014-09-02 Thread David Belohrad
Dear All,

I have my emacs/notmuch installation setup such, that I send the emails
usually directly using local exim4 installation. For particular 'From:'
field however I need to use my work server. Nowadays I do that
manually. Hence if I write an email using my work address, I manually
call a function switching the exim4 to work server. when the mail is
sent, i manually set it back to exim.

could that scenario be somehow fitted automatically, so when I overwrite
the default 'From:' address (by hand. is it possible to do some
automatic cycling?) to work address, so that message sender in emacs
would automatically use work exchange server to deliver the mail?


many thanks


david


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


[PATCH] emacs: jump: sort-order bugfix

2014-09-02 Thread Mark Walters
default-value needs its argument to be quoted.
---

Slightly strangely default-value of 't or nil is 't or nil
respectively so the code didn't give an error but just did the wrong
thing.

Thanks to Jani for finding the bug.

Best wishes

Mark

 emacs/notmuch-jump.el |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
index 5eb0949..0193f8c 100644
--- a/emacs/notmuch-jump.el
+++ b/emacs/notmuch-jump.el
@@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
 (case (plist-get saved-search :sort-order)
   (newest-first nil)
   (oldest-first t)
-  (otherwise (default-value notmuch-search-oldest-first)
+  (otherwise (default-value 'notmuch-search-oldest-first)
(push (list key name
`(lambda () (notmuch-search ',query ',oldest-first)))
  action-map)
-- 
1.7.10.4

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


Re: sending email using different server for different 'From:' field

2014-09-02 Thread Keith Amidon
On Tue, 2014-09-02 at 14:26 +0200, David Belohrad wrote:
 could that scenario be somehow fitted automatically, so when I overwrite
 the default 'From:' address (by hand. is it possible to do some
 automatic cycling?) to work address, so that message sender in emacs
 would automatically use work exchange server to deliver the mail?

I think this is more of a message-mode question than a notmuch question.
I use something very similar to code attached below, which is rather
brute-force, but does the job for me.

 --- Keith

-

(defun kea/send-mail-with-x ()
  (interactive)
  (setq smtpmail-smtp-server smtp.x.com
smtpmail-smtp-service 587
smtpmail-local-domain x.com
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/send-mail-with-y ()
  (interactive)
  (setq smtpmail-smtp-server email.y.com
smtpmail-smtp-service 587
smtpmail-local-domain y.com
smtpmail-auth-user nil
smtpmail-stream-type 'starttls))

(defun kea/message-select-mail-dest ()
  (cond ((string-match k...@x.com
   (message-field-value From))
 (kea/send-mail-with-x))
(t
 (kea/send-mail-with-y

(kea/send-mail-with-y)
(add-hook 'message-send-hook 'kea/message-select-mail-dest)



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


Re: [PATCH] doc: 'rm -f' potential doxygen temporary output file

2014-09-02 Thread David Bremner
Tomi Ollila tomi.oll...@iki.fi writes:

 Some (older) Doxygen versions do not create such a temporary file.

 ---

pushed.

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


Re: [PATCH] emacs: jump: sort-order bugfix

2014-09-02 Thread Carl Worth
Mark Walters markwalters1...@gmail.com writes:
 default-value needs its argument to be quoted.
 ---

Hi Mark,

I really appreciate you sending in a bug fix. Thanks!

I'd prefer to see the commit message describing the bug and the fix a
bit.

You do have some text here that would be a great addition to the commit
message:

 Slightly strangely default-value of 't or nil is 't or nil
 respectively so the code didn't give an error but just did the wrong
 thing.

But even beyond that. What is the wrong thing that the code did here?

Imagine someone (me!) trying to read and review the patch without ever
encountering the bug before. How can I test the bug both before and
after applying the patch?

I'd really like to see that information in the commit message.

Thanks,

-Carl


pgpkfzqsTF18i.pgp
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


[PATCH v2] emacs: jump: sort-order bugfix

2014-09-02 Thread Mark Walters
default-value needs its argument to be quoted.

Slightly strangely default-value of 't or nil is 't or nil
respectively so the code

(default-value notmuch-search-oldest-first)

just gives the current value of notmuch-search-oldest-first rather
than intended default-value of this variable.

The symptom is that if you are in a search buffer and use notmuch jump
to run a saved search which does not have an explicitly set sort order
then the sort order of the saved-search is inherited from the current
search buffer rather than being the default search order.

Thanks to Jani for finding the bug.
---

This time with a fuller commit message.

(Part of the reason I did not send more before is I had not checked
what the exact outcome of the buggy code was: it was obvious what the
code was intended to do, and that with the extra quote it
would do what it was intended to do.)

Best wishes

Mark







 emacs/notmuch-jump.el |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
index 5eb0949..0193f8c 100644
--- a/emacs/notmuch-jump.el
+++ b/emacs/notmuch-jump.el
@@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
 (case (plist-get saved-search :sort-order)
   (newest-first nil)
   (oldest-first t)
-  (otherwise (default-value notmuch-search-oldest-first)
+  (otherwise (default-value 'notmuch-search-oldest-first)
(push (list key name
`(lambda () (notmuch-search ',query ',oldest-first)))
  action-map)
-- 
1.7.10.4

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


Re: [PATCH v2] emacs: jump: sort-order bugfix

2014-09-02 Thread Austin Clements
LGTM.

Quoth Mark Walters on Sep 02 at  7:56 pm:
 default-value needs its argument to be quoted.
 
 Slightly strangely default-value of 't or nil is 't or nil
 respectively so the code
 
 (default-value notmuch-search-oldest-first)
 
 just gives the current value of notmuch-search-oldest-first rather
 than intended default-value of this variable.
 
 The symptom is that if you are in a search buffer and use notmuch jump
 to run a saved search which does not have an explicitly set sort order
 then the sort order of the saved-search is inherited from the current
 search buffer rather than being the default search order.
 
 Thanks to Jani for finding the bug.
 ---
 
 This time with a fuller commit message.
 
 (Part of the reason I did not send more before is I had not checked
 what the exact outcome of the buggy code was: it was obvious what the
 code was intended to do, and that with the extra quote it
 would do what it was intended to do.)
 
 Best wishes
 
 Mark
 
 
 
 
 
 
 
  emacs/notmuch-jump.el |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
 index 5eb0949..0193f8c 100644
 --- a/emacs/notmuch-jump.el
 +++ b/emacs/notmuch-jump.el
 @@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
(case (plist-get saved-search :sort-order)
  (newest-first nil)
  (oldest-first t)
 -(otherwise (default-value notmuch-search-oldest-first)
 +(otherwise (default-value 'notmuch-search-oldest-first)
   (push (list key name
   `(lambda () (notmuch-search ',query ',oldest-first)))
 action-map)
___
notmuch mailing list
notmuch@notmuchmail.org
http://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2] emacs: jump: sort-order bugfix

2014-09-02 Thread Jani Nikula
On Tue, 02 Sep 2014, Mark Walters markwalters1...@gmail.com wrote:
 default-value needs its argument to be quoted.

 Slightly strangely default-value of 't or nil is 't or nil
 respectively so the code

 (default-value notmuch-search-oldest-first)

 just gives the current value of notmuch-search-oldest-first rather
 than intended default-value of this variable.

 The symptom is that if you are in a search buffer and use notmuch jump
 to run a saved search which does not have an explicitly set sort order
 then the sort order of the saved-search is inherited from the current
 search buffer rather than being the default search order.

 Thanks to Jani for finding the bug.

This fixes the issue, thanks for the patch.

Jani.



 ---

 This time with a fuller commit message.

 (Part of the reason I did not send more before is I had not checked
 what the exact outcome of the buggy code was: it was obvious what the
 code was intended to do, and that with the extra quote it
 would do what it was intended to do.)

 Best wishes

 Mark







  emacs/notmuch-jump.el |2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/emacs/notmuch-jump.el b/emacs/notmuch-jump.el
 index 5eb0949..0193f8c 100644
 --- a/emacs/notmuch-jump.el
 +++ b/emacs/notmuch-jump.el
 @@ -51,7 +51,7 @@ (defun notmuch-jump-search ()
(case (plist-get saved-search :sort-order)
  (newest-first nil)
  (oldest-first t)
 -(otherwise (default-value notmuch-search-oldest-first)
 +(otherwise (default-value 'notmuch-search-oldest-first)
   (push (list key name
   `(lambda () (notmuch-search ',query ',oldest-first)))
 action-map)
 -- 
 1.7.10.4

 ___
 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: How to debug 'ignoring non-mail file' issues

2014-09-02 Thread Jani Nikula
On Mon, 01 Sep 2014, Perttu Luukko perttu.luu...@iki.fi wrote:
 Yes, upgrading to GMime 2.6.20 caused all the messages on my server
 classified as mail.

What was the old version? If it was 2.4 we should probably consider
dropping support for that in future notmuch.

 Even more reason to give a separate warning for GMime parse errors.

Not sure. We only get a binary success/fail from GMime, and that gets
printed for all non-email files. I'm not sure it's helpful.

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


Re: How to debug 'ignoring non-mail file' issues

2014-09-02 Thread Perttu Luukko
On 2014-09-02 23:37:12, Jani Nikula wrote:
 On Mon, 01 Sep 2014, Perttu Luukko perttu.luu...@iki.fi wrote:
  Yes, upgrading to GMime 2.6.20 caused all the messages on my server
  classified as mail.
 
 What was the old version? If it was 2.4 we should probably consider
 dropping support for that in future notmuch.

It was 2.4.33. It might still work for other people, I don't know. I
still have some ignored mails. If I can nail down why they are ignored
we might now more about why GMime 2.4 ignored even more mail. They were
from around the same time period, so it might have something to do with
the email setup I had at that time.

  Even more reason to give a separate warning for GMime parse errors.
 
 Not sure. We only get a binary success/fail from GMime, and that gets
 printed for all non-email files. I'm not sure it's helpful.

What I mean that there would be a separate error for cases Does not
resemble an email message at all, i.e., some control file your mail
server happens to store in the mailbox, and Looks like mail but we
can't parse it, i.e., better find out why it can't be parsed to avoid
potentially important messages going missing from the database.

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