Re: emacs: honoring notmuch-show-insert-part-text/html for 'w3m renderer

2021-07-31 Thread David Edmondson
On Saturday, 2021-07-31 at 00:18:45 +01, Jose Antonio Ortega Ruiz wrote:

> Hi,
>
> notmuch-show-insert-part-text/html correctly binds shr-blocked-images to
> notmuch-show-text/html-blocked-images when using 'shr as the
> mm-text-html-renderer.  However, when the latter is not shr, the
> function only binds gnus-blocked-images, which is not used by the 'w3m
> rendered.  The corresponding variable to bind is in the latter case
> w3m-ignored-image-url-regexp, and something like the simple patch below
> seem to make things work, at least for me.

Patch looks good.

Reviewed-by: David Edmondson 

> Cheers,
> jao
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 9a95eb34..0c4fc110 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -823,7 +823,8 @@ will return nil if the CID is unknown or cannot be
> retrieved."
>  (let ((mm-inline-text-html-with-w3m-keymap nil)
>   ;; FIXME: If we block an image, offer a button to load external
>   ;; images.
> - (gnus-blocked-images notmuch-show-text/html-blocked-images))
> + (gnus-blocked-images notmuch-show-text/html-blocked-images)
> + (w3m-ignored-image-url-regexp
> notmuch-show-text/html-blocked-images))
>(notmuch-show-insert-part-*/* msg part content-type nth depth
> button
>
>  ;;; Functions used by notmuch-show--insert-part-text/html-shr
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] emacs: Add compatibility for org-msg.el

2021-06-24 Thread David Edmondson
On Thursday, 2021-06-24 at 14:20:24 -04, Ori wrote:

> Thanks for the suggestion, David. Can the commit message be changed or
> should I resubmit? An elaborated version:

That's a question for bremner. Re-submitting will probably make his life
easier.

> -
>
> Enable `notmuch-company` with `org-msg`, which does not derive from
> `message-mode` in composing. This change was first proposed in the
> discussion here:
> 
>
> -
>
> Thanks,
>
> Ori
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Hello? Is anybody home? Well, you don't know me, but I know you.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] emacs: Add compatibility for org-msg.el

2021-06-23 Thread David Edmondson
On Tuesday, 2021-06-22 at 17:48:50 -04, Ori wrote:

> See https://github.com/jeremy-compostella/org-msg/issues/53

It would be nice to have an inline description of the change, as the
github repository might disappear at some point, but the fix looks
reasonable.

Reviewed-by: David Edmondson 

> ---
>  NEWS | 2 ++
>  emacs/notmuch-company.el | 3 ++-
>  2 files changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/NEWS b/NEWS
> index 09456f60..c167c9a2 100644
> --- a/NEWS
> +++ b/NEWS
> @@ -8,6 +8,8 @@ Emacs
>  previous behaviour of using notmuch to send mail by default, customize
>  `mail-user-agent` to `notmuch-user-agent`.
>  
> +`notmuch-company` now works in `org-msg`.
> +
>  Vim
>  ---
>  
> diff --git a/emacs/notmuch-company.el b/emacs/notmuch-company.el
> index c6a004ae..7e05dc8f 100644
> --- a/emacs/notmuch-company.el
> +++ b/emacs/notmuch-company.el
> @@ -70,7 +70,8 @@
>   (completion-ignore-case t))
>  (cl-case command
>(interactive (company-begin-backend 'notmuch-company))
> -  (prefix (and (derived-mode-p 'message-mode)
> +  (prefix (and (or (derived-mode-p 'message-mode)
> +(derived-mode-p 'org-msg-edit-mode))
>  (looking-back
>   (concat notmuch-address-completion-headers-regexp ".*")
>   (line-beginning-position))
> -- 
> 2.25.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
There's someone in my head but it's not me.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 2/2] emacs: Prefer email address over User ID when showing valid signature

2021-06-07 Thread David Edmondson
On Wednesday, 2021-05-26 at 21:44:59 -04, Daniel Kahn Gillmor wrote:

> Most concrete verification steps are likely only taken on the e-mail
> address in the first place, and e-mail addresses render more
> intelligibly than arbitrary User IDs in the first place.
>
> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  emacs/notmuch-crypto.el | 15 ++-
>  1 file changed, 10 insertions(+), 5 deletions(-)
>
> diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
> index db7cb75d..5c260a7a 100644
> --- a/emacs/notmuch-crypto.el
> +++ b/emacs/notmuch-crypto.el
> @@ -119,14 +119,19 @@ mode."
>  (cond
>   ((string= status "good")
>(let ((fingerprint (concat "0x" (plist-get sigstatus :fingerprint)))
> + (email (plist-get sigstatus :email))
>   (userid (plist-get sigstatus :userid)))
> - ;; If userid is present it has full or greater validity.
> - (if userid
> + ;; If email or userid are present, they have full or greater validity.
> + (if email

Could this not be something like:

(when (or email userid)
  (setq label (concat "Good signature by: " (or email userid)))
  ...
  )

?

>   (progn
> -   (setq label (concat "Good signature by: " userid))
> +   (setq label (concat "Good signature by: " email))
> (setq face 'notmuch-crypto-signature-good))
> -   (setq label (concat "Good signature by key: " fingerprint))
> -   (setq face 'notmuch-crypto-signature-good-key))
> +   (if userid
> +   (progn
> + (setq label (concat "Good signature by: " userid))
> + (setq face 'notmuch-crypto-signature-good))
> + (setq label (concat "Good signature by key: " fingerprint))
> + (setq face 'notmuch-crypto-signature-good-key)))
>   (setq button-action 'notmuch-crypto-sigstatus-good-callback)
>   (setq help-msg (concat "Click to list key ID 0x" fingerprint "."
>   ((string= status "error")
> -- 
> 2.30.2
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
If I could buy my reasoning, I'd pay to lose.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 7/9] doc: document (tersely) the intended behaviour of relative paths.

2021-05-07 Thread David Edmondson
On Friday, 2021-05-07 at 08:30:27 -03, David Bremner wrote:

> ---
>  doc/man1/notmuch-config.rst | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/doc/man1/notmuch-config.rst b/doc/man1/notmuch-config.rst
> index 32290a38..5cb6e203 100644
> --- a/doc/man1/notmuch-config.rst
> +++ b/doc/man1/notmuch-config.rst
> @@ -44,7 +44,9 @@ configuration file and corresponding database.
>  characters. In a multiple-value item (a list), the values are
>  separated by semicolon characters.
>  
> -The available configuration items are described below.
> +The available configuration items are described below. Non-absolute
> +paths are expanded relative to `$HOME` for items in section

Maybe "presumed" rather than "expanded"?

> +**database**.
>  
>  **database.path**
>  Notmuch will store its database here, (in
> -- 
> 2.30.2
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Freedom is just a song by Wham!.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v2 0/2] scaffolding for autocrypt support

2021-04-19 Thread David Edmondson
On Friday, 2021-04-16 at 09:05:29 -03, David Bremner wrote:

> Daniel Kahn Gillmor  writes:
>
>> Hi David, all--
>>
>> On Sun 2021-02-21 15:21:30 +, David Edmondson wrote:
>>> I started looking at how to add autocrypt support based on
>>> https://git.sr.ht/~zge/autocrypt.
>>
>> Thanks for this work, i'm glad to see the interest in autocrypt!
>>
>> I tend to think that the autocrypt handling belongs in libnotmuch, and
>> not just in the emacs frontend, so i'm a bit concerned about what we'll
>> have to prune out of the emacs frontend if we do manage to land the
>> features in libnotmuch itself.
>
> FTR, I'm waiting for the two of you to come to some concensus before
> proceding with these patches.

At the moment I don't really have time to make any progress, sorry.

dme.
-- 
Welcome to Conditioning.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 1/2] emacs: with-current-notmuch-show-message should return the result of body

2021-02-21 Thread David Edmondson
Rather than returning the result of kill-buffer,
with-current-notmuch-show-message should return the result of calling
the passed body.
---
 emacs/notmuch-show.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index ba93febb..761be252 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -273,11 +273,12 @@ position of the message in the thread."
   `(save-excursion
  (let ((id (notmuch-show-get-message-id)))
(let ((buf (generate-new-buffer (concat "*notmuch-msg-" id "*"
-(with-current-buffer buf
-  (let ((coding-system-for-read 'no-conversion))
-(call-process notmuch-command nil t nil "show" "--format=raw" id))
-  ,@body)
-(kill-buffer buf)
+(prog1
+ (with-current-buffer buf
+   (let ((coding-system-for-read 'no-conversion))
+ (call-process notmuch-command nil t nil "show" "--format=raw" id))
+   ,@body)
+ (kill-buffer buf))
 
 (defun notmuch-show-turn-on-visual-line-mode ()
   "Enable Visual Line mode."
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 0/2] scaffolding for autocrypt support

2021-02-21 Thread David Edmondson
I started looking at how to add autocrypt support based on
https://git.sr.ht/~zge/autocrypt.

Sending seems straightforward, as far as I understand autocrypt, at
least.

Dealing with inbound messages requires a few framework changes in
the existing notmuch emacs code, which is these two patches.

I'll send autocrypt patches after some more testing and
improvement. Currently things are pretty inefficient -
autocrypt-notmuch-header will request the raw message on every call,
which is expensive if the message is large.

v2:
- Rebased on master (bremner).

David Edmondson (2):
  emacs: with-current-notmuch-show-message should return the result of
body
  emacs: Add notmuch-show-insert-msg-hook

 emacs/notmuch-show.el | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 2/2] emacs: Add notmuch-show-insert-msg-hook

2021-02-21 Thread David Edmondson
Add a hook called after inserting each message into the buffer showing
messages.
---
 emacs/notmuch-show.el | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 761be252..cda0bfe0 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -113,6 +113,12 @@ visible for any given message."
   :group 'notmuch-show
   :group 'notmuch-hooks)
 
+(defcustom notmuch-show-insert-msg-hook nil
+  "Functions called after inserting a message."
+  :type 'hook
+  :group 'notmuch-show
+  :group 'notmuch-hooks)
+
 (defcustom notmuch-show-max-text-part-size 10
   "Maximum size of a text part to be shown by default in characters.
 
@@ -1112,7 +1118,9 @@ is t, hide the part initially and show the button."
 ;; Message visibility depends on whether it matched the search
 ;; criteria.
 (notmuch-show-message-visible msg (and (plist-get msg :match)
-  (not (plist-get msg :excluded))
+  (not (plist-get msg :excluded
+
+(run-hooks 'notmuch-show-insert-msg-hook)))
 
 ;;; Toggle commands
 
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v3 1/3] emacs: Use pcase in notmuch-search-insert-field

2021-02-21 Thread David Edmondson
Rather than lots of string-equal calls, use the pcase macro.
---
 emacs/notmuch.el | 40 
 1 file changed, 20 insertions(+), 20 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 6d37c623..b9cee19c 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -830,26 +830,26 @@ non-authors is found, assume that all of the authors 
match."
   (insert padding
 
 (defun notmuch-search-insert-field (field format-string result)
-  (cond
-   ((string-equal field "date")
-(insert (propertize (format format-string (plist-get result 
:date_relative))
-   '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)))
-   ((string-equal field "subject")
-(insert (propertize (format format-string
-   (notmuch-sanitize (plist-get result :subject)))
-   'face 'notmuch-search-subject)))
-   ((string-equal field "authors")
-(notmuch-search-insert-authors
- format-string (notmuch-sanitize (plist-get result :authors
-   ((string-equal field "tags")
-(let ((tags (plist-get result :tags))
- (orig-tags (plist-get result :orig-tags)))
-  (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
+  (pcase field
+("date"
+ (insert (propertize (format format-string (plist-get result 
:date_relative))
+'face 'notmuch-search-date)))
+("count"
+ (insert (propertize (format format-string
+(format "[%s/%s]" (plist-get result :matched)
+(plist-get result :total)))
+'face 'notmuch-search-count)))
+("subject"
+ (insert (propertize (format format-string
+(notmuch-sanitize (plist-get result :subject)))
+'face 'notmuch-search-subject)))
+("authors"
+ (notmuch-search-insert-authors format-string
+   (notmuch-sanitize (plist-get result 
:authors
+("tags"
+ (let ((tags (plist-get result :tags))
+  (orig-tags (plist-get result :orig-tags)))
+   (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
 
 (defun notmuch-search-show-result (result pos)
   "Insert RESULT at POS."
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v3 3/3] emacs: Allow functions in notmuch-{tree,unthreaded}-result-format

2021-02-21 Thread David Edmondson
If the car of an element in notmuch-tree-result-format or
notmuch-unthreaded-result-format is a function, insert the result of
calling the function into the buffer.
---
 emacs/notmuch-tree.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index 13007a13..ffb21496 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -866,6 +866,9 @@ unchanged ADDRESS if parsing fails."
  ((listp field)
   (format format-string (notmuch-tree-format-field-list field msg)))
 
+ ((functionp field)
+  (funcall field format-string msg))
+
  ((string-equal field "date")
   (let ((face (if match
  'notmuch-tree-match-date-face
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v3 2/3] emacs: Allow functions in notmuch-search-result-format

2021-02-21 Thread David Edmondson
If the car of an element in notmuch-search-result-format is a
function, insert the result of calling the function into the buffer.

This allows a user to generate custom fields in the output of a search
result. For example, with:

(defun -notmuch-result-flags (format-string result)
  (let ((tags-to-letters '(("flagged" . "!")
   ("unread" . "u")
   ("mine" . "m")
   ("sent" . "s")
   ("replied" . "r")))
(tags (plist-get result :tags)))

(format format-string
(mapconcat (lambda (t2l)
 (if (member (car t2l) tags)
 (cdr t2l)
   " "))
   tags-to-letters ""

(setq notmuch-search-result-format '((-notmuch-result-flags . "%s ")
 ("date" . "%12s ")
 ("count" . "%9s ")
 ("authors" . "%-30s ")
 ("subject" . "%s ")
 ("tags" . "(%s)")))

The first few characters on each line of the search result are used to
show information about some significant tags associated with the
thread.
---
 emacs/notmuch.el | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index b9cee19c..6ba535d1 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -831,6 +831,8 @@ non-authors is found, assume that all of the authors match."
 
 (defun notmuch-search-insert-field (field format-string result)
   (pcase field
+((pred functionp)
+ (insert (funcall field format-string result)))
 ("date"
  (insert (propertize (format format-string (plist-get result 
:date_relative))
 'face 'notmuch-search-date)))
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v3 0/3] Allow functions in notmuch-*-result-format

2021-02-21 Thread David Edmondson
As well as allowing headers to be specified in the various result
format lists, allow functions that can be used to implement per-user
logic when generating the results.

v3:
- Push the function test into the pcase (bremner).
- Rebase to master (bremner).

David Edmondson (3):
  emacs: Use pcase in notmuch-search-insert-field
  emacs: Allow functions in notmuch-search-result-format
  emacs: Allow functions in notmuch-{tree,unthreaded}-result-format

 emacs/notmuch-tree.el |  3 +++
 emacs/notmuch.el  | 42 ++
 2 files changed, 25 insertions(+), 20 deletions(-)

-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [RFC PATCH] show: Add support for -format=raw -body=false

2021-02-05 Thread David Edmondson
On Thursday, 2021-02-04 at 22:33:06 -04, David Bremner wrote:

> David Edmondson  writes:
>
>>> I'm just nervous about more legacy formats. I think we will get the
>>> arbitrary headers thing working eventually, but I can see it might take
>>> some time.
>>
>> Are we ever likely to get rid of the raw format? I use it quite a bit,
>> and it seems to be relatively low complexity and simple to support.
>
> It isn't completely without maintenance overhead, but I agree it's not
> going away. I can live with the body=false option if you think it's
> better / more feasible than the arbitrary headers series.

At the moment I'm using the former because the latter is missing, but in
principle I think that they might fill different needs. Could we have
both?

dme.
-- 
I just bite it, it's for the look I don't light it.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2] emacs: When completing tags, offer each tag once

2021-02-03 Thread David Edmondson
When prompting for one or more tags to add or remove to/from one or
more threads, ensure that the set of tags offered for completion
contains no duplicates.

Some completion packages (e.g. selectrum) will include every member of
the offered list, resulting in the same tag being indicated as a
possibility several times.
---
Use `delete-dups' rather than hand-coding similar.

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

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 26efcccd..6d37c623 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -577,7 +577,7 @@ thread."
 (notmuch-search-foreach-result beg end
   (lambda (pos)
(setq output (append output (notmuch-search-get-tags pos)
-output))
+(delete-dups output)))
 
 (defun notmuch-search-interactive-tag-changes (&optional initial-input)
   "Prompt for tag changes for the current thread or region.
-- 
2.30.0
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] emacs: When completing tags, offer each tag once

2021-02-01 Thread David Edmondson
On Monday, 2021-02-01 at 11:49:36 -04, David Bremner wrote:

> David Edmondson  writes:
>>  
>> +(defun notmuch-search-uniq-tags (tags)
>> +  (let (result)
>> +(mapc (lambda (tag)
>> +(unless (member tag result)
>> +  (push tag result)))
>> +  tags)
>> +result))
>
> I leave elisp style to others...

Me too :-)

> Is there some bound on the length of tags? Otherwise this seems like
> it's potentially a bit slow?

No, there isn't any bound. I'd be surprised to see lists longer than low
tens of elements.

For similar functionality the dash library provides `-distinct', which
uses a lookup table if there are more than 32 elements in the list,
claiming that this is the break-point for the hash based approach to be
faster.

I'm a bit loath to just re-implement that. Am I allowed to depend on
dash? (I'd guess not, but figured that it's worth asking.)

dme.
-- 
Why stay in college? Why go to night school?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH] emacs: When completing tags, offer each tag once

2021-02-01 Thread David Edmondson
When prompting for one or more tags to add or remove to/from one or
more threads, ensure that the set of tags offered for completion
contains no duplicates.

Some completion packages (e.g. selectrum) will include every member of
the offered list, resulting in the same tag being indicated as a
possibility several times.
---
 emacs/notmuch.el | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 26efcccd..ceec5b5d 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -572,12 +572,20 @@ thread."
 (defun notmuch-search-get-tags (&optional pos)
   (plist-get (notmuch-search-get-result pos) :tags))
 
+(defun notmuch-search-uniq-tags (tags)
+  (let (result)
+(mapc (lambda (tag)
+   (unless (member tag result)
+ (push tag result)))
+ tags)
+result))
+
 (defun notmuch-search-get-tags-region (beg end)
   (let (output)
 (notmuch-search-foreach-result beg end
   (lambda (pos)
(setq output (append output (notmuch-search-get-tags pos)
-output))
+(notmuch-search-uniq-tags output)))
 
 (defun notmuch-search-interactive-tag-changes (&optional initial-input)
   "Prompt for tag changes for the current thread or region.
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [RFC PATCH] show: Add support for -format=raw -body=false

2021-01-18 Thread David Edmondson
On Monday, 2021-01-18 at 14:28:02 -04, David Bremner wrote:

> David Edmondson  writes:
>> Now, it would be nice to be able to say something like...
>>
>> notmuch show --format=sexp --body=false \
>>   --headers=received-by,face,x-face \
>>   id:foo
>>
>> ...to get some extra headers in the sexp output, but I didn't look at it
>> yet.
>
> There was a series at id:20191122230730.35712-2-johan.pa...@gmail.com
> that got stalled due to (I think) some issues with passing around
> configuration information.

I will go and look at this.

>> The proposed change seems like a simple, obvious improvement that is
>> entirely in-line with the existing interface and implementation. Is
>> there any reason not to do it?
>
> I'm just nervous about more legacy formats. I think we will get the
> arbitrary headers thing working eventually, but I can see it might take
> some time.

Are we ever likely to get rid of the raw format? I use it quite a bit,
and it seems to be relatively low complexity and simple to support.

dme.
-- 
They must have taken my marbles away.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [RFC PATCH] show: Add support for -format=raw -body=false

2021-01-18 Thread David Edmondson
On Monday, 2021-01-18 at 13:37:08 -04, David Bremner wrote:

> David Edmondson  writes:
>
>> Similar to other formats, allow the body to be omitted when outputting
>> raw messages.
>>
>> This can be used by UI code to get the full headers of a message
>> without the need to consume the body, which may be large.
>
> I guess I'm a bit confused why this is for "raw" format, and not
> "text". Are you proposing that we have two ad-hoc output formats for
> consuming by scripts and other tools that don't want JSON or SEXP?

"text" is a strange archaic output format, the rationale for which seems
lost in time :-)

"notmuch show --format=text --body=false id:foo" already works, but
doesn't provide a complete set of headers - it's limited to subject,
from, to, date, *cc, ...

I wanted to get the Autocrypt or Face headers, so ended up using
"--format=raw", but then end up with the entire message, which can be
megabytes large. With the emacs UI, that means pulling all of that data
into a buffer, just to ignore it.

Now, it would be nice to be able to say something like...

notmuch show --format=sexp --body=false \
  --headers=received-by,face,x-face \
  id:foo

...to get some extra headers in the sexp output, but I didn't look at it
yet.

The proposed change seems like a simple, obvious improvement that is
entirely in-line with the existing interface and implementation. Is
there any reason not to do it?

dme.
-- 
Don't you know you're never going to get to France.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: notmuch-hello-mode-map removed

2021-01-17 Thread David Edmondson
On Sunday, 2021-01-17 at 15:16:20 -05, Jon Fineman wrote:

> I just upgraded my notmuch library and noticed that per this thread the
> function notmuch-hello-mode-map was removed.
> https://nmbug.notmuchmail.org/nmweb/show/20200726165818.400-14-jonas%40bernoul.li
>
> I had been following this guide to map keys to various notmuch
> functions.
> https://notmuchmail.org/emacstips/#index5h2
>
> For example I have this mapping:
> (define-key notmuch-hello-mode-map "i"
>   (lambda ()
> (interactive)
> (notmuch-hello-search "folder:INBOX not tag:deleted")))

Use "notmuch-search" rather than "notmuch-hello-search" here.

> Still being very new to emacs and elisp I am having trouble coming up
> with how to replace notmuch-hello-mode-map with another fuction.
>
> Any help would be appreciated.
>
> Thanks.
>
> Jon
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Paris and London, baby, you can keep.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[RFC PATCH] show: Add support for -format=raw -body=false

2021-01-17 Thread David Edmondson
Similar to other formats, allow the body to be omitted when outputting
raw messages.

This can be used by UI code to get the full headers of a message
without the need to consume the body, which may be large.
---
 notmuch-show.c | 28 +---
 1 file changed, 25 insertions(+), 3 deletions(-)

diff --git a/notmuch-show.c b/notmuch-show.c
index dd836add..f52e6a40 100644
--- a/notmuch-show.c
+++ b/notmuch-show.c
@@ -888,6 +888,8 @@ format_part_raw (unused (const void *ctx), unused 
(sprinter_t *sp),
ssize_t ssize;
char buf[4096];
notmuch_status_t ret = NOTMUCH_STATUS_FILE_ERROR;
+   unsigned int cr_count = 0;
+   notmuch_bool_t done = false;
 
filename = notmuch_message_get_filename (node->envelope_file);
if (filename == NULL) {
@@ -901,13 +903,32 @@ format_part_raw (unused (const void *ctx), unused 
(sprinter_t *sp),
goto DONE;
}
 
-   while (! g_mime_stream_eos (stream)) {
+   while (! done && ! g_mime_stream_eos (stream)) {
ssize = g_mime_stream_read (stream, buf, sizeof (buf));
if (ssize < 0) {
fprintf (stderr, "Error: Read failed from %s\n", filename);
goto DONE;
}
 
+   if (! params->output_body) {
+   /*
+* Look for two adjacent newlines, as they mark the
+* separation of the headers from the body.
+*/
+   for (ssize_t off = 0; off < ssize; off++) {
+   if (buf[off] == '\n') {
+   cr_count++;
+   } else {
+   cr_count = 0;
+   }
+   if (cr_count == 2) {
+   ssize = off;
+   done = true;
+   break;
+   }
+   }
+   }
+
if (ssize > 0 && fwrite (buf, ssize, 1, stdout) != 1) {
fprintf (stderr, "Error: Write %ld chars to stdout failed\n", 
ssize);
goto DONE;
@@ -1310,9 +1331,10 @@ notmuch_show_command (notmuch_config_t *config, int 
argc, char *argv[])
} else {
if (format != NOTMUCH_FORMAT_TEXT &&
format != NOTMUCH_FORMAT_JSON &&
-   format != NOTMUCH_FORMAT_SEXP)
+   format != NOTMUCH_FORMAT_SEXP &&
+   format != NOTMUCH_FORMAT_RAW)
fprintf (stderr,
-"Warning: --body=false only implemented for 
format=text, format=json and format=sexp\n");
+"Warning: --body=false is not implemented for 
format=mbox\n");
}
 }
 
-- 
2.20.1
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 3/3] emacs: Allow functions in notmuch-{tree,unthreaded}-result-format

2021-01-12 Thread David Edmondson
If the car of an element in notmuch-tree-result-format or
notmuch-unthreaded-result-format is a function, insert the result of
calling the function into the buffer.
---
 emacs/notmuch-tree.el | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
index f342f85a..6643bf92 100644
--- a/emacs/notmuch-tree.el
+++ b/emacs/notmuch-tree.el
@@ -849,6 +849,9 @@ unchanged ADDRESS if parsing fails."
  ((listp field)
   (format format-string (notmuch-tree-format-field-list field msg)))
 
+ ((functionp field)
+  (funcall field format-string msg))
+
  ((string-equal field "date")
   (let ((face (if match
  'notmuch-tree-match-date-face
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 2/3] emacs: Allow functions in notmuch-search-result-format

2021-01-12 Thread David Edmondson
If the car of an element in notmuch-search-result-format is a
function, insert the result of calling the function into the buffer.

This allows a user to generate custom fields in the output of a search
result. For example, with:

(defun -notmuch-result-flags (format-string result)
  (let ((tags-to-letters '(("flagged" . "!")
   ("unread" . "u")
   ("mine" . "m")
   ("sent" . "s")
   ("replied" . "r")))
(tags (plist-get result :tags)))

(format format-string
(mapconcat (lambda (t2l)
 (if (member (car t2l) tags)
 (cdr t2l)
   " "))
   tags-to-letters ""

(setq notmuch-search-result-format '((-notmuch-result-flags . "%s ")
 ("date" . "%12s ")
 ("count" . "%9s ")
 ("authors" . "%-30s ")
 ("subject" . "%s ")
 ("tags" . "(%s)")))

The first few characters on each line of the search result are used to
show information about some significant tags associated with the
thread.
---
 emacs/notmuch.el | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index efbf5bd0..92cb5202 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -824,26 +824,31 @@ non-authors is found, assume that all of the authors 
match."
   (insert padding
 
 (defun notmuch-search-insert-field (field format-string result)
-  (pcase field
-("date"
- (insert (propertize (format format-string (plist-get result 
:date_relative))
-'face 'notmuch-search-date)))
-("count"
- (insert (propertize (format format-string
-(format "[%s/%s]" (plist-get result :matched)
-(plist-get result :total)))
-'face 'notmuch-search-count)))
-("subject"
- (insert (propertize (format format-string
-(notmuch-sanitize (plist-get result :subject)))
-'face 'notmuch-search-subject)))
-("authors"
- (notmuch-search-insert-authors format-string
-   (notmuch-sanitize (plist-get result 
:authors
-("tags"
- (let ((tags (plist-get result :tags))
-  (orig-tags (plist-get result :orig-tags)))
-   (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
+  (cond
+   ((functionp field)
+(insert (funcall field format-string result)))
+
+   ((stringp field)
+(pcase field
+  ("date"
+   (insert (propertize (format format-string (plist-get result 
:date_relative))
+  'face 'notmuch-search-date)))
+  ("count"
+   (insert (propertize (format format-string
+  (format "[%s/%s]" (plist-get result :matched)
+  (plist-get result :total)))
+  'face 'notmuch-search-count)))
+  ("subject"
+   (insert (propertize (format format-string
+  (notmuch-sanitize (plist-get result 
:subject)))
+  'face 'notmuch-search-subject)))
+  ("authors"
+   (notmuch-search-insert-authors format-string
+ (notmuch-sanitize (plist-get result 
:authors
+  ("tags"
+   (let ((tags (plist-get result :tags))
+(orig-tags (plist-get result :orig-tags)))
+(insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)
 
 (defun notmuch-search-show-result (result pos)
   "Insert RESULT at POS."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 1/3] emacs: Use pcase in notmuch-search-insert-field

2021-01-12 Thread David Edmondson
Rather than lots of string-equal calls, use the pcase macro.
---
 emacs/notmuch.el | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 83bcee57..efbf5bd0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -65,7 +65,9 @@
 
 ;;; Code:
 
-(eval-when-compile (require 'cl-lib))
+(eval-when-compile
+  (require 'cl-lib)
+  (require 'pcase))
 
 (require 'mm-view)
 (require 'message)
@@ -822,26 +824,26 @@ non-authors is found, assume that all of the authors 
match."
   (insert padding
 
 (defun notmuch-search-insert-field (field format-string result)
-  (cond
-   ((string-equal field "date")
-(insert (propertize (format format-string (plist-get result 
:date_relative))
-   '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)))
-   ((string-equal field "subject")
-(insert (propertize (format format-string
-   (notmuch-sanitize (plist-get result :subject)))
-   'face 'notmuch-search-subject)))
-   ((string-equal field "authors")
-(notmuch-search-insert-authors
- format-string (notmuch-sanitize (plist-get result :authors
-   ((string-equal field "tags")
-(let ((tags (plist-get result :tags))
- (orig-tags (plist-get result :orig-tags)))
-  (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
+  (pcase field
+("date"
+ (insert (propertize (format format-string (plist-get result 
:date_relative))
+'face 'notmuch-search-date)))
+("count"
+ (insert (propertize (format format-string
+(format "[%s/%s]" (plist-get result :matched)
+(plist-get result :total)))
+'face 'notmuch-search-count)))
+("subject"
+ (insert (propertize (format format-string
+(notmuch-sanitize (plist-get result :subject)))
+'face 'notmuch-search-subject)))
+("authors"
+ (notmuch-search-insert-authors format-string
+   (notmuch-sanitize (plist-get result 
:authors
+("tags"
+ (let ((tags (plist-get result :tags))
+  (orig-tags (plist-get result :orig-tags)))
+   (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
 
 (defun notmuch-search-show-result (result pos)
   "Insert RESULT at POS."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH v2 0/3] Allow functions in notmuch-*-result-format

2021-01-12 Thread David Edmondson
As well as allowing headers to be specified in the various result
format lists, allow functions that can be used to implement per-user
logic when generating the results.

David Edmondson (3):
  emacs: Use pcase in notmuch-search-insert-field
  emacs: Allow functions in notmuch-search-result-format
  emacs: Allow functions in notmuch-{tree,unthreaded}-result-format

 emacs/notmuch-tree.el |  3 +++
 emacs/notmuch.el  | 47 +--
 2 files changed, 30 insertions(+), 20 deletions(-)

-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 0/4] emacs: avoid type errors due to nil as content-type

2021-01-10 Thread David Edmondson
On Sunday, 2021-01-10 at 19:47:18 +01, Jonas Bernoulli wrote:

> The fourth commit tries to address the issue raised in
> id:87k0sxa6c3@fifthhorseman.net.
>
>   The output of "notmuch show --format=sexp --format-version=4"
>   may contain `:content-type' entries with `nil' as the value,
>   when it fails to detect the correct value.  Account for that
>   in a few places where we would otherwise risk a type error.
>
> The other three commits cleanup the code I had to look at to do
> the above, because I just can't help myself.
>
> This does not apply without first applying
> id:20201214162401.19569-1-jo...@bernoul.li.

I don't seem to have this one, but that could be a problem at my end.

Anyway, for the series...

Reviewed-by: David Edmondson 

>
>  Jonas
>
> Jonas Bernoulli (4):
>   emacs: notmuch-mua-add-more-hidden-headers: use local binding
>   emacs: notmuch-show--register-cids: fix names of bindings
>   emacs: notmuch-show--get-cid-content: cosmetics
>   emacs: avoid type errors due to nil as content-type
>
>  emacs/notmuch-lib.el  | 23 --
>  emacs/notmuch-mua.el  |  7 +++
>  emacs/notmuch-show.el | 46 +--
>  3 files changed, 39 insertions(+), 37 deletions(-)
>
> -- 
> 2.30.0
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
It was a perfectly good grand piano.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[autocrypt RFC PATCH] Add support for the notmuch mua

2021-01-10 Thread David Edmondson
---
This is very much an RFC patch, as I'm new to autocrypt. It's also a
patch for autocrypt (https://git.sr.ht/~zge/autocrypt) rather than
notmuch, but it made more sense to send it here first, I think.

Comments welcomed.

 autocrypt-notmuch.el | 103 +++
 autocrypt.el |  11 +
 2 files changed, 114 insertions(+)
 create mode 100644 autocrypt-notmuch.el

diff --git a/autocrypt-notmuch.el b/autocrypt-notmuch.el
new file mode 100644
index 000..f365be2
--- /dev/null
+++ b/autocrypt-notmuch.el
@@ -0,0 +1,103 @@
+;;; autocrypt-notmuch.el --- Autocrypt for Notmuch -*- lexical-binding:t -*-
+
+;; Author: David Edmondson 
+;; Version: 0.4.0
+;; Keywords: comm
+;; Package-Requires: ((emacs "25.1"))
+;; URL: https://git.sr.ht/~zge/autocrypt
+
+;; This file is NOT part of Emacs.
+;;
+;; This file is in the public domain, to the extent possible under law,
+;; published under the CC0 1.0 Universal license.
+;;
+;; For a full copy of the CC0 license see
+;; https://creativecommons.org/publicdomain/zero/1.0/legalcode
+
+;;; Commentary:
+
+;; MUA specific functions for Notmuch
+;;
+;; Set up with:
+;;   (autocrypt-notmuch-install)
+
+;;; Code:
+
+(eval-when-compile
+  (require 'pcase))
+
+(require 'notmuch-show)
+
+(defvar autocrypt-notmuch-headers-id nil)
+(defvar autocrypt-notmuch-headers-cache nil)
+
+;;;###autoload
+(defun autocrypt-notmuch-install ()
+  "Install autocrypt hooks for Notmuch."
+  (add-hook 'notmuch-show-insert-msg-hook #'autocrypt-process-header))
+
+(defun autocrypt-notmuch-uninstall ()
+  "Remove autocrypt hooks for Notmuch."
+  (remove-hook 'notmuch-show-insert-msg-hook #'autocrypt-process-header)
+
+  (when (and (bufferp autocrypt-notmuch-headers-cache)
+ (buffer-live-p autocrypt-notmuch-headers-cache))
+(kill-buffer autocrypt-notmuch-headers-cache)))
+
+(defun autocrypt-notmuch-header-1 (field)
+  "Return the FIELD header for the currently shown message."
+
+  ;; Currently it is can be expensive to retrieve FIELD if the message
+  ;; is large, as this function examines a raw copy of the complete
+  ;; message in a buffer. Given that autocrypt will require several
+  ;; headers from each message and therefore make repeated calls to
+  ;; `autocrypt-notmuch-header', attempt to alleviate this cost using
+  ;; a single element cache containing the headers of any requested
+  ;; message.
+
+  ;; This would be improved if:
+  ;;   notmuch show --format=raw --body=false
+  ;; worked.
+
+  (let ((id (notmuch-show-get-message-id t)))
+;; If the current header cache is not for this message, make it
+;; so.
+(unless (and (string= id autocrypt-notmuch-headers-id)
+ (bufferp autocrypt-notmuch-headers-cache)
+ (buffer-live-p autocrypt-notmuch-headers-cache))
+  (setq autocrypt-notmuch-headers-id id
+autocrypt-notmuch-headers-cache (get-buffer-create 
"*autocrypt-notmuch-headers-cache*"))
+
+  (with-current-notmuch-show-message
+   ;; Keep only the headers in the cache - the body is not
+   ;; required.
+   (mail-narrow-to-head)
+
+   (let ((content (buffer-substring (point-min) (point-max
+ (with-current-buffer autocrypt-notmuch-headers-cache
+   (erase-buffer)
+   (insert content))
+
+  (with-current-buffer autocrypt-notmuch-headers-cache
+(mail-fetch-field field)))
+
+(defun autocrypt-notmuch-header (field)
+  "Ask Notmuch to return header FIELD for the current message."
+
+  (pcase field
+;; Some headers are cached in the message properties - retrieving
+;; them is faster than extracting the raw message and parsing it.
+("Cc" (notmuch-show-get-date))
+("Date" (notmuch-show-get-date))
+("From" (notmuch-show-get-from))
+("To" (notmuch-show-get-date))
+(_
+ ;; If this is not a matching message, don't bother looking more
+ ;; deeply, given that `autocrypt-notmuch-headers-1' can be
+ ;; expensive for large messages.
+ (when (plist-get (notmuch-show-get-message-properties) :match)
+   (autocrypt-notmuch-header-1 field)
+
+(provide 'autocrypt-notmuch)
+
+;;; autocrypt-notmuch.el ends here
diff --git a/autocrypt.el b/autocrypt.el
index 965f661..01c36c1 100644
--- a/autocrypt.el
+++ b/autocrypt.el
@@ -115,6 +115,15 @@ Every member of this list has to be an instance of the
  :sign-encrypt autocrypt-message-sign-encrypt
  :secure-attach autocrypt-message-secure-attach
  :encrypted-p mml-secure-is-encrypted-p)
+(notmuch
+ :install autocrypt-notmuch-install
+ :uninstall autocrypt-notmuch-uninstall
+ :header autocrypt-notmuch-header
+ :add-header autocrypt-message-add-header
+ :remove-header message-remove-header
+ :sign-encrypt autocrypt-message-sign-encrypt
+ :secure-attach autocry

Re: emacs-notmuch: notmuch-show-hook runs too early

2021-01-08 Thread David Edmondson
On Tuesday, 2021-01-05 at 09:45:52 +01, yoctocell wrote:

> I am using a package called gnus-article-treat-patch[0] which colorizes
> patches in emails. It works expected when I manually call
> `ft/gnus-article-treat-patch' in a notmuch-show buffer, but it doesn't
> work when I add it as a hook.

Is there a reason not to use notmuch-wash-convert-inline-patch-to-part?

It doesn't do quite as much (nothing for the header), but the patch
should be appropriately rendered.

> (add-hook 'notmuch-show-hook 'ft/gnus-article-treat-patch)
>
> `notmuch-show-hook' seems to be called too early so
> `ft/gnus-article-treat-patch' isn't able to read the contents of the
> message and apply any highlighting.
>
> I managed to get it to work with the following patch.
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 056c4e30..f9f3bdb1 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -1317,11 +1317,11 @@ If no messages match the query return NIL."
> (notmuch-sanitize
>  (notmuch-show-strip-re
>   (notmuch-show-get-subject)
> -  (run-hooks 'notmuch-show-hook)
>(if state
> (notmuch-show-apply-state state)
>   ;; With no state to apply, just go to the first message.
> - (notmuch-show-goto-first-wanted-message)))
> + (notmuch-show-goto-first-wanted-message))
> +  (run-hooks 'notmuch-show-hook))
>  ;; Report back to the caller whether any messages matched.
>  forest))
>
> [0]: https://github.com/velkyel/gnus-article-treat-patch
>
> -- 
> yoctocell
> 8B88 2502 31D7 03B1 68BC  2691 3851 020D 7E61 BBC2
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
He caught a fleeting glimpse of a man, moving uphill pursued by a bus.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 2/2] emacs: Add notmuch-show-insert-msg-hook

2021-01-08 Thread David Edmondson
Add a hook called after inserting each message into the buffer showing
messages.
---
 emacs/notmuch-show.el | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index 222c9dae..292677bc 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -111,6 +111,12 @@ visible for any given message."
   :group 'notmuch-show
   :group 'notmuch-hooks)
 
+(defcustom notmuch-show-insert-msg-hook nil
+  "Functions called after inserting a message."
+  :type 'hook
+  :group 'notmuch-show
+  :group 'notmuch-hooks)
+
 (defcustom notmuch-show-max-text-part-size 10
   "Maximum size of a text part to be shown by default in characters.
 
@@ -1104,7 +1110,9 @@ is t, hide the part initially and show the button."
 ;; Message visibility depends on whether it matched the search
 ;; criteria.
 (notmuch-show-message-visible msg (and (plist-get msg :match)
-  (not (plist-get msg :excluded))
+  (not (plist-get msg :excluded
+
+(run-hooks 'notmuch-show-insert-msg-hook)))
 
 (defun notmuch-show-toggle-process-crypto ()
   "Toggle the processing of cryptographic MIME parts."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 1/2] emacs: with-current-notmuch-show-message should return the result of body

2021-01-08 Thread David Edmondson
Rather than returning the result of kill-buffer,
with-current-notmuch-show-message should return the result of calling
the passed body.
---
 emacs/notmuch-show.el | 11 ++-
 1 file changed, 6 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index b08ceb97..222c9dae 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -272,11 +272,12 @@ position of the message in the thread."
   `(save-excursion
  (let ((id (notmuch-show-get-message-id)))
(let ((buf (generate-new-buffer (concat "*notmuch-msg-" id "*"
-(with-current-buffer buf
-  (let ((coding-system-for-read 'no-conversion))
-(call-process notmuch-command nil t nil "show" "--format=raw" id))
-  ,@body)
-(kill-buffer buf)
+(prog1
+ (with-current-buffer buf
+   (let ((coding-system-for-read 'no-conversion))
+ (call-process notmuch-command nil t nil "show" "--format=raw" id))
+   ,@body)
+ (kill-buffer buf))
 
 (defun notmuch-show-turn-on-visual-line-mode ()
   "Enable Visual Line mode."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 0/2] scaffolding for autocrypt support

2021-01-08 Thread David Edmondson
I started looking at how to add autocrypt support based on
https://git.sr.ht/~zge/autocrypt.

Sending seems straightforward, as far as I understand autocrypt, at
least.

Dealing with inbound messages requires a few framework changes in the
existing notmuch emacs code, which is these two patches. They are not
autocrypt specific, and could be generally useful.

I'll send autocrypt patches after some more testing and
improvement. Currently things are pretty inefficient -
autocrypt-notmuch-header will request the raw message on every call,
which is expensive if the message is large.

David Edmondson (2):
  emacs: with-current-notmuch-show-message should return the result of
body
  emacs: Add notmuch-show-insert-msg-hook

 emacs/notmuch-show.el | 21 +++--
 1 file changed, 15 insertions(+), 6 deletions(-)

-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: help with :search-type 'tree' in Emacs/notmuch config?

2021-01-08 Thread David Edmondson
On Friday, 2021-01-08 at 07:44:45 -08, Jonathan Wilner wrote:

> Great idea. I tried it and got the same result - not opening in Tree mode. :-(

Please show us the (complete) value of your notmuch-saved-searches
variable.

You can get it by going to the *scratch* buffer and typing
notmuch-saved-searches, followed by control-j (sorry if that's obvious,
just wanted to be sure).

dme.
-- 
Oliver darling, call Mister Haney, I think our speakers are blown.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 2/2] emacs: Allow functions in notmuch-search-result-format

2021-01-07 Thread David Edmondson
If the car of an element in notmuch-search-result-format is a
function, insert the result of calling the function into the buffer.

This allows a user to generate custom fields in the output of a search
result. For example, with:

(defun -notmuch-result-flags (format-string result)
  (let ((tags-to-letters '(("flagged" . "!")
   ("unread" . "u")
   ("mine" . "m")
   ("sent" . "s")
   ("replied" . "r")))
(tags (plist-get result :tags)))

(format format-string
(mapconcat (lambda (t2l)
 (if (member (car t2l) tags)
 (cdr t2l)
   " "))
   tags-to-letters ""

(setq notmuch-search-result-format '((-notmuch-result-flags . "%s ")
 ("date" . "%12s ")
 ("count" . "%9s ")
 ("authors" . "%-30s ")
 ("subject" . "%s ")
 ("tags" . "(%s)")))

The first few characters on each line of the search result are used to
show information about some significant tags associated with the
thread.
---
 emacs/notmuch.el | 45 +
 1 file changed, 25 insertions(+), 20 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index efbf5bd0..92cb5202 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -824,26 +824,31 @@ non-authors is found, assume that all of the authors 
match."
   (insert padding
 
 (defun notmuch-search-insert-field (field format-string result)
-  (pcase field
-("date"
- (insert (propertize (format format-string (plist-get result 
:date_relative))
-'face 'notmuch-search-date)))
-("count"
- (insert (propertize (format format-string
-(format "[%s/%s]" (plist-get result :matched)
-(plist-get result :total)))
-'face 'notmuch-search-count)))
-("subject"
- (insert (propertize (format format-string
-(notmuch-sanitize (plist-get result :subject)))
-'face 'notmuch-search-subject)))
-("authors"
- (notmuch-search-insert-authors format-string
-   (notmuch-sanitize (plist-get result 
:authors
-("tags"
- (let ((tags (plist-get result :tags))
-  (orig-tags (plist-get result :orig-tags)))
-   (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
+  (cond
+   ((functionp field)
+(insert (funcall field format-string result)))
+
+   ((stringp field)
+(pcase field
+  ("date"
+   (insert (propertize (format format-string (plist-get result 
:date_relative))
+  'face 'notmuch-search-date)))
+  ("count"
+   (insert (propertize (format format-string
+  (format "[%s/%s]" (plist-get result :matched)
+  (plist-get result :total)))
+  'face 'notmuch-search-count)))
+  ("subject"
+   (insert (propertize (format format-string
+  (notmuch-sanitize (plist-get result 
:subject)))
+  'face 'notmuch-search-subject)))
+  ("authors"
+   (notmuch-search-insert-authors format-string
+ (notmuch-sanitize (plist-get result 
:authors
+  ("tags"
+   (let ((tags (plist-get result :tags))
+(orig-tags (plist-get result :orig-tags)))
+(insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)
 
 (defun notmuch-search-show-result (result pos)
   "Insert RESULT at POS."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


[PATCH 1/2] emacs: Use pcase in notmuch-search-insert-field

2021-01-07 Thread David Edmondson
Rather than lots of string-equal calls, use the pcase macro.
---
 emacs/notmuch.el | 44 +++-
 1 file changed, 23 insertions(+), 21 deletions(-)

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 83bcee57..efbf5bd0 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -65,7 +65,9 @@
 
 ;;; Code:
 
-(eval-when-compile (require 'cl-lib))
+(eval-when-compile
+  (require 'cl-lib)
+  (require 'pcase))
 
 (require 'mm-view)
 (require 'message)
@@ -822,26 +824,26 @@ non-authors is found, assume that all of the authors 
match."
   (insert padding
 
 (defun notmuch-search-insert-field (field format-string result)
-  (cond
-   ((string-equal field "date")
-(insert (propertize (format format-string (plist-get result 
:date_relative))
-   '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)))
-   ((string-equal field "subject")
-(insert (propertize (format format-string
-   (notmuch-sanitize (plist-get result :subject)))
-   'face 'notmuch-search-subject)))
-   ((string-equal field "authors")
-(notmuch-search-insert-authors
- format-string (notmuch-sanitize (plist-get result :authors
-   ((string-equal field "tags")
-(let ((tags (plist-get result :tags))
- (orig-tags (plist-get result :orig-tags)))
-  (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
+  (pcase field
+("date"
+ (insert (propertize (format format-string (plist-get result 
:date_relative))
+'face 'notmuch-search-date)))
+("count"
+ (insert (propertize (format format-string
+(format "[%s/%s]" (plist-get result :matched)
+(plist-get result :total)))
+'face 'notmuch-search-count)))
+("subject"
+ (insert (propertize (format format-string
+(notmuch-sanitize (plist-get result :subject)))
+'face 'notmuch-search-subject)))
+("authors"
+ (notmuch-search-insert-authors format-string
+   (notmuch-sanitize (plist-get result 
:authors
+("tags"
+ (let ((tags (plist-get result :tags))
+  (orig-tags (plist-get result :orig-tags)))
+   (insert (format format-string (notmuch-tag-format-tags tags 
orig-tags)))
 
 (defun notmuch-search-show-result (result pos)
   "Insert RESULT at POS."
-- 
2.29.2
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: consistent database corruption with notmuch new

2020-12-14 Thread David Edmondson
Which filesystem are you using for the mail store?

I had similar looking problems when using ZFS and never got to the
bottom of it.

dme.
-- 
Why does it have to be like this? I can never tell.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 00/23] Another set up Emacs cleanup

2020-11-16 Thread David Edmondson
On Monday, 2020-11-16 at 22:28:20 +01, Jonas Bernoulli wrote:

> This remove the first four commits, which have already been
> applied to master.  It also makes requested minor changes
> to the three marked commits.

For the set...

Reviewed-by: David Edmondson 

> Jonas Bernoulli (23):
>   emacs: remove redundant notmuch-hello-trim
>   emacs: fix old bug in notmuch-mua-mail
>   emacs: remove kludge for Emacs 23 from notmuch-mua-mail
>   emacs: more cleanup since dropping support for Emacs 24
>   emacs: sanitize function that displays version
>   emacs: define notmuch-hello-url as a constant
>   emacs: shorten/replace first sentence of a few doc-strings
>   emacs: place only first sentence on first doc-string line
> * emacs: place complete first sentence on first doc-string line
>   emacs: always use elisp quoting style in doc-strings
> * emacs: misc doc-string improvements
>   emacs: remove deprecated notmuch-folder command
>   emacs: remove unnecessary notmuch-remove-if-not
>   emacs: remove unused notmuch-address-locate-command
>   emacs: remove unnecessary notmuch-tree-button-activate
>   emacs: inline notmuch-documentation-first-line
>   emacs: inline notmuch-split-content-type
>   emacs: use defvar-local
>   emacs: use setq-local
>   emacs: use setq instead set
>   emacs: do not quote self-quoting t
>   emacs: avoid binding unnamed commands in keymaps
> * emacs: various cosmetic improvements
>
>  emacs/coolj.el   |   4 +-
>  emacs/notmuch-address.el |  58 
>  emacs/notmuch-company.el |   7 +-
>  emacs/notmuch-compat.el  |   9 +-
>  emacs/notmuch-crypto.el  |   7 +-
>  emacs/notmuch-draft.el   |  17 ++--
>  emacs/notmuch-hello.el   | 123 +
>  emacs/notmuch-jump.el|   5 --
>  emacs/notmuch-lib.el | 108 +-
>  emacs/notmuch-maildir-fcc.el |  12 +--
>  emacs/notmuch-mua.el |  64 ++---
>  emacs/notmuch-parser.el  |   5 +-
>  emacs/notmuch-show.el|  56 ++--
>  emacs/notmuch-tag.el |  24 ++---
>  emacs/notmuch-tree.el| 170 ++-
>  emacs/notmuch.el | 108 +++---
>  16 files changed, 331 insertions(+), 446 deletions(-)
>
> -- 
> 2.29.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Come down, come talk to me.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v2] emacs: add notmuch-expr, sexp-style queries

2020-11-16 Thread David Edmondson
On Friday, 2020-11-13 at 23:01:22 +11, Tom Fitzhenry wrote:

> From: Tom Fitzhenry 
>
> notmuch-expr allows you to write notmuch search queries in sexp style like:
>
> (notmuch-expr
>   '(and
> (to "emacs-devel")
> "info manual"
> (or
>   (not (is "spam"))
>   (is "important"
>
> which will generate the textual query:
>
> "to:emacs-devel AND (NOT is:spam OR is:important) AND \"info manual\""

Reviewed-by: David Edmondson 

> ---
>  emacs/Makefile.local   |   1 +
>  emacs/notmuch-expr-test.el |  96 
>  emacs/notmuch-expr.el  | 124 +
>  emacs/notmuch.el   |   1 +
>  4 files changed, 222 insertions(+)
>  create mode 100644 emacs/notmuch-expr-test.el
>  create mode 100644 emacs/notmuch-expr.el
>
> diff --git a/emacs/Makefile.local b/emacs/Makefile.local
> index d1b320c3..f68e6e31 100644
> --- a/emacs/Makefile.local
> +++ b/emacs/Makefile.local
> @@ -22,6 +22,7 @@ emacs_sources := \
>   $(dir)/notmuch-version.el \
>   $(dir)/notmuch-jump.el \
>   $(dir)/notmuch-company.el \
> + $(dir)/notmuch-expr.el \
>   $(dir)/notmuch-draft.el
>  
>  elpa_sources := ${emacs_sources} $(dir)/notmuch-pkg.el
> diff --git a/emacs/notmuch-expr-test.el b/emacs/notmuch-expr-test.el
> new file mode 100644
> index ..92029fec
> --- /dev/null
> +++ b/emacs/notmuch-expr-test.el
> @@ -0,0 +1,96 @@
> +(require 'ert)
> +(require 'notmuch-expr)
> +
> +(ert-deftest and ()
> +  (should
> +(equal
> +  "(\"valued\" AND is:unread AND from:s...@example.com)"
> +  (notmuch-expr
> +   '(and
> + "valued"
> + (is "unread")
> + (from "s...@example.com"))
> +
> +(ert-deftest body ()
> +  (should
> +   (equal
> +"(body:wallace AND from:gromit)"
> +(notmuch-expr
> + '(and
> +   (body "wallace")
> +   (from "gromit"))
> +
> +(ert-deftest regex ()
> +  (should
> +   (equal
> +"(subject:\"/Ca+sh/\" AND NOT is:important)"
> +(notmuch-expr
> + '(and
> +   (subject "/Ca+sh/")
> +   (not (is "important")))
> +
> +(ert-deftest precedence ()
> +  (should
> +   (equal
> +"(to:emacs-devel AND (NOT is:spam OR is:important))"
> +(notmuch-expr
> + '(and
> +   (to "emacs-devel")
> +   (or
> + (not (is "spam"))
> + (is "important")))
> +
> +(ert-deftest xor ()
> +  (should
> +   (equal
> +"is:inbox XOR is:sent"
> +(notmuch-expr
> + '(xor
> +   (is "inbox")
> +   (is "sent"))
> +
> +(ert-deftest literal ()
> +  (should
> +   (equal
> +"(is:inbox OR from:foo)"
> +(notmuch-expr
> + '(or
> +   (is "inbox")
> +   (literal "from:foo"))
> +
> +(ert-deftest string ()
> +  (should
> +   (equal
> +"(is:inbox OR \"from:foo\")"
> +(notmuch-expr
> + '(or
> +   (is "inbox")
> +   "from:foo")
> +
> +(ert-deftest tag-with-spaces ()
> +  (should
> +   (equal
> +"is:\"a tag\""
> +(notmuch-expr
> + '(tag "a tag")
> +
> +(ert-deftest quoted-spaces ()
> +  (should
> +   (equal
> +"subject:\"Hello there\""
> +(notmuch-expr
> + '(subject "Hello there")
> +
> +(ert-deftest quoted-backslash ()
> +  (should
> +   (equal
> +"subject:\"A celebration! \\o/ Woo.\""
> +(notmuch-expr
> + '(subject "A celebration! \\o/ Woo.")
> +
> +(ert-deftest quoted-quote ()
> +  (should
> +   (equal
> +"subject:\"Gandalf: \\\"Use the force!\\\" 2001\""
> +(notmuch-expr
> + '(subject "Gandalf: \"Use the force!\" 2001")
> diff --git a/emacs/notmuch-expr.el b/emacs/notmuch-expr.el
> new file mode 100644
> index ..f5a3429f
> --- /dev/null
> +++ b/emacs/notmuch-expr.el
> @@ -0,0 +1,124 @@
> +;;; notmuch-expr.el --- An S-exp library for building notmuch search queries 
> -*- lexical-binding: t; -*-
> +
> +;; Author: Tom Fitzhenry 
> +;; Package-Requires: ((emacs "24.1"))
> +;; URL: https://notmuchmail.org
> +
> +;;; Commentary:
> +
> +;;

Re: [PATCH 27/27] emacs: various cosmetic improvements

2020-11-15 Thread David Edmondson
On Sunday, 2020-11-08 at 20:03:11 +01, Jonas Bernoulli wrote:

There were some places here where you capitalised comments (more
generally, turned them into English prose) when they were moving for
$reasons, and others where you left them alone. Was there a rationale
for the different treatment?

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-address.el | 31 ++
>  emacs/notmuch-hello.el   | 28 +
>  emacs/notmuch-lib.el | 38 +
>  emacs/notmuch-mua.el | 10 ++---
>  emacs/notmuch-tag.el |  2 +-
>  emacs/notmuch.el | 88 
>  6 files changed, 91 insertions(+), 106 deletions(-)
>
> diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
> index 21d1d82f..0dedd5d5 100644
> --- a/emacs/notmuch-address.el
> +++ b/emacs/notmuch-address.el
> @@ -21,6 +21,8 @@
>  
>  ;;; Code:
>  
> +(eval-when-compile (require 'cl-lib))
> +
>  (require 'message)
>  (require 'notmuch-parser)
>  (require 'notmuch-lib)
> @@ -154,15 +156,12 @@ (defcustom notmuch-address-use-company t
>:group 'notmuch-address)
>  
>  (defun notmuch-address-setup ()
> -  (let* ((setup-company (and notmuch-address-use-company
> -  (require 'company nil t)))
> -  (pair (cons notmuch-address-completion-headers-regexp
> -  #'notmuch-address-expand-name)))
> -(when setup-company
> -  (notmuch-company-setup))
> -(unless (member pair message-completion-alist)
> -  (setq message-completion-alist
> - (push pair message-completion-alist)
> +  (when (and notmuch-address-use-company
> +  (require 'company nil t))
> +(notmuch-company-setup))
> +  (cl-pushnew (cons notmuch-address-completion-headers-regexp
> + #'notmuch-address-expand-name)
> +   message-completion-alist :test #'equal))
>  
>  (defun notmuch-address-toggle-internal-completion ()
>"Toggle use of internal completion for current buffer.
> @@ -251,11 +250,8 @@ (defun notmuch-address-expand-name ()
> (t nil)))
>  
>  (defun notmuch-address-harvest-addr (result)
> -  (let ((name-addr (plist-get result :name-addr)))
> -(puthash name-addr t notmuch-address-completions)))
> -
> -(defun notmuch-address-harvest-handle-result (obj)
> -  (notmuch-address-harvest-addr obj))
> +  (puthash (plist-get result :name-addr)
> +t notmuch-address-completions))
>  
>  (defun notmuch-address-harvest-filter (proc string)
>(when (buffer-live-p (process-buffer proc))
> @@ -264,7 +260,7 @@ (defun notmuch-address-harvest-filter (proc string)
>   (goto-char (point-max))
>   (insert string))
>(notmuch-sexp-parse-partial-list
> -   'notmuch-address-harvest-handle-result (process-buffer proc)
> +   'notmuch-address-harvest-addr (process-buffer proc)
>  
>  (defvar notmuch-address-harvest-procs '(nil . nil)
>"The currently running harvests.
> @@ -375,7 +371,7 @@ (defun notmuch-address--load-address-hash ()
>  (defun notmuch-address--save-address-hash ()
>(when notmuch-address-save-filename
>  (if (or (not (file-exists-p notmuch-address-save-filename))
> - ;; The file exists, check it is a file we saved
> + ;; The file exists, check it is a file we saved.
>   (notmuch-address--get-address-hash))
>   (with-temp-file notmuch-address-save-filename
> (let ((save-plist
> @@ -398,8 +394,7 @@ (defun notmuch-address-harvest-trigger ()
> nil nil
> (lambda (proc event)
>;; If harvest fails, we want to try
> -  ;; again when the trigger is next
> -  ;; called
> +  ;; again when the trigger is next called.
>(if (string= event "finished\n")
>(progn
>  (notmuch-address--save-address-hash)
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index fa31694f..80af7544 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -402,8 +402,7 @@ (defun notmuch-hello-add-saved-search (widget)
>  ;; If an existing saved search with this name exists, remove it.
>  (setq notmuch-saved-searches
> (cl-loop for elem in notmuch-saved-searches
> -if (not (equal name
> -   (notmuch-saved-search-get elem :name)))
> +unless (equal name (notmuch-saved-search-get elem :name))
>  collect elem))
>  ;; Add the new one.
>  (customize-save-variable 'notmuch-saved-searches
> @@ -446,18 +445,14 @@ (defun notmuch-hello-reflect (list ncols)
>append (not

Re: [PATCH 15/27] emacs: misc doc-string improvements

2020-11-15 Thread David Edmondson
On Sunday, 2020-11-08 at 20:02:59 +01, Jonas Bernoulli wrote:

Minor suggestion below...

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-address.el | 6 +++---
>  emacs/notmuch-crypto.el  | 4 ++--
>  emacs/notmuch-mua.el | 7 ---
>  3 files changed, 9 insertions(+), 8 deletions(-)
>
> diff --git a/emacs/notmuch-address.el b/emacs/notmuch-address.el
> index 561cc140..04353522 100644
> --- a/emacs/notmuch-address.el
> +++ b/emacs/notmuch-address.el
> @@ -36,9 +36,9 @@ (defvar notmuch-address-completions (make-hash-table :test 
> 'equal)
>  This variable is set by calling `notmuch-address-harvest'.")
>  
>  (defvar notmuch-address-full-harvest-finished nil
> -  "t indicates that full completion address harvesting has been finished.
> -Use notmuch-address--harvest-ready to access as that will load a
> -saved hash if necessary (and available).")
> +  "Whether full completion address harvesting has finished.
> +Use notmuch-address--harvest-ready to access as that will load

Quotes to indicate that `notmuch-address--harvest-ready' is a function?

> +a saved hash if necessary (and available).")
>  
>  (defun notmuch-address--harvest-ready ()
>"Return t if there is a full address hash available.
> diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
> index 4fab215a..9e6f3a9d 100644
> --- a/emacs/notmuch-crypto.el
> +++ b/emacs/notmuch-crypto.el
> @@ -27,7 +27,7 @@ (require 'notmuch-lib)
>  (declare-function notmuch-show-get-message-id "notmuch-show" (&optional 
> bare))
>  
>  (defcustom notmuch-crypto-process-mime t
> -  "Should cryptographic MIME parts be processed?
> +  "Whether to process cryptographic MIME parts.
>  
>  If this variable is non-nil signatures in multipart/signed
>  messages will be verified and multipart/encrypted parts will be
> @@ -46,7 +46,7 @@ (defcustom notmuch-crypto-process-mime t
>:group 'notmuch-crypto)
>  
>  (defcustom notmuch-crypto-get-keys-asynchronously t
> -  "Retrieve gpg keys asynchronously."
> +  "Whether to retrieve openpgp keys asynchronously."
>:type 'boolean
>:group 'notmuch-crypto)
>  
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 62d615d1..821bb324 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -82,10 +82,11 @@ (defgroup notmuch-reply nil
>:group 'notmuch)
>  
>  (defcustom notmuch-mua-cite-function 'message-cite-original
> -  "*Function for citing an original message.
> +  "Function for citing an original message.
> +
>  Predefined functions include `message-cite-original' and
> -`message-cite-original-without-signature'.
> -Note that these functions use `mail-citation-hook' if that is non-nil."
> +`message-cite-original-without-signature'.  Note that these
> +functions use `mail-citation-hook' if that is non-nil."
>:type '(radio (function-item message-cite-original)
>   (function-item message-cite-original-without-signature)
>   (function-item sc-cite-original)
> -- 
> 2.29.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
I'm not the reason you're looking for redemption.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 13/27] emacs: place complete first sentence on first doc-string line

2020-11-15 Thread David Edmondson
On Sunday, 2020-11-08 at 20:02:57 +01, Jonas Bernoulli wrote:

With a suggested rewording below...

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-crypto.el |  3 +--
>  emacs/notmuch-hello.el  |  3 +--
>  emacs/notmuch-mua.el| 11 ---
>  3 files changed, 6 insertions(+), 11 deletions(-)
>
> diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
> index 276c9859..4fab215a 100644
> --- a/emacs/notmuch-crypto.el
> +++ b/emacs/notmuch-crypto.el
> @@ -103,8 +103,7 @@ (define-button-type 'notmuch-crypto-status-button-type
>:supertype 'notmuch-button-type)
>  
>  (defun notmuch-crypto-insert-sigstatus-button (sigstatus from)
> -  "Insert a button describing the signature status SIGSTATUS sent
> -by user FROM."
> +  "Insert a button describing the signature status SIGSTATUS sent by user 
> FROM."
>(let* ((status (plist-get sigstatus :status))
>(show-button t)
>(face 'notmuch-crypto-signature-unknown)
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index 003bec33..28784345 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -372,8 +372,7 @@ (defvar notmuch-hello-hidden-sections nil
>"List of sections titles whose contents are hidden.")
>  
>  (defvar notmuch-hello-first-run t
> -  "True if `notmuch-hello' is run for the first time, set to nil
> -afterwards.")
> +  "True if `notmuch-hello' is run for the first time, set to nil 
> afterwards.")
>  
>  (defun notmuch-hello-nice-number (n)
>(let (result)
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 9d08c2c9..62d615d1 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -73,8 +73,7 @@ (defcustom notmuch-mua-user-agent-function nil
>:group 'notmuch-send)
>  
>  (defcustom notmuch-mua-hidden-headers nil
> -  "Headers that are added to the `message-mode' hidden headers
> -list."
> +  "Headers that are added to the `message-mode' hidden headers list."
>:type '(repeat string)
>:group 'notmuch-send)
>  
> @@ -167,8 +166,7 @@ (defun notmuch-mua-get-switch-function ()
>   (t (error "Invalid value for `notmuch-mua-compose-in'"
>  
>  (defun notmuch-mua-maybe-set-window-dedicated ()
> -  "Set the selected window as dedicated according to
> -`notmuch-mua-compose-in'."
> +  "Set the selected window as dedicated according to 
> `notmuch-mua-compose-in'."
>(when (or (eq notmuch-mua-compose-in 'new-frame)
>   (eq notmuch-mua-compose-in 'new-window))
>  (set-window-dedicated-p (selected-window) t)))
> @@ -335,9 +333,8 @@ (define-derived-mode notmuch-message-mode message-mode 
> "Message[Notmuch]"
>  (put 'notmuch-message-mode 'flyspell-mode-predicate 
> 'mail-mode-flyspell-verify)
>  
>  (defun notmuch-mua-pop-to-buffer (name switch-function)
> -  "Pop to buffer NAME, and warn if it already exists and is
> -modified. This function is notmuch adaptation of
> -`message-pop-to-buffer'."
> +  "Pop to buffer NAME, and warn if it already exists and is modified.
> +This function is notmuch adaptation of `message-pop-to-buffer'."

"notmuch's adaptation" or "a notmuch adaptation", or just "an adaptation".

>(let ((buffer (get-buffer name)))
>  (if (and buffer
>(buffer-name buffer))
> -- 
> 2.29.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
You bring light in.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH 06/27] emacs: fix old bug in notmuch-mua-mail

2020-11-15 Thread David Edmondson
On Sunday, 2020-11-08 at 20:02:50 +01, Jonas Bernoulli wrote:

> This fixes a regression introduced in [1: 7e20d264].  If the argument
> RETURN-ACTION was non-nil then we should pass along the value of that
> argument.  Instead we passed along the constant symbol `return-action'.
>
> 1: 7e20d26480553f57d53bd9ec28cae163c1ac91e3
>emacs: Fix mail composition under Emacs 23

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-mua.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-mua.el b/emacs/notmuch-mua.el
> index 616b625c..1204fb6a 100644
> --- a/emacs/notmuch-mua.el
> +++ b/emacs/notmuch-mua.el
> @@ -402,7 +402,7 @@ (defun notmuch-mua-mail (&optional to subject 
> other-headers continue
>  ;; argument. Pass it only if it is supplied by the caller. This
>  ;; will never be the case when we're called by `compose-mail' in
>  ;; Emacs 23.
> -(when return-action (nconc args '(return-action)))
> +(when return-action (nconc args (list return-action)))
>  (apply 'message-setup-1 headers args))
>(notmuch-fcc-header-setup)
>(message-sort-headers)
> -- 
> 2.29.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
This is not how I woke up, but it's how I look now.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Problems with unicode characters under emacs and Xorg

2020-11-02 Thread David Edmondson
On Monday, 2020-11-02 at 04:26:27 -08, David Mazieres wrote:

> dm-list-email-notm...@scs.stanford.edu writes:
>
>> I just installed the ttf-symbola package from AUR and ran fc-cache (not
>> sure if necessary).  Now the problem is completely gone.  Not only that,
>> but I even get the little memo symbol instead of a box with the hex code
>> point number.
>>
>> Thank you so much!  This was driving me nuts for months.
>
> Sadly, I spoke too soon.  This does fix the particular problem that I
> posted, and makes the situation better, but I'm still getting occasional
> lockups, presumably because symbola does not cover every possible
> symbol.  For example, I had another email containing U+8BDD (CJK UNIFIED
> IDEOGRAPH-8BDD), and this one still caused my emacs to spin for many
> minutes, before displaying a box with 8BDD in it.

That one is from:

-isas-song ti-medium-r-normal--16-160-72-72-c-160-gb2312.1980-0

though I'm not sure which package provides that.

> So unfortunately the problem seems to be that any character not
> supported by an installed font takes about 2-5 minutes of CPU time to
> resolve.  And of course most characters that I'd use are in installed
> fonts, except that I can control what's in the emails I receive, so this
> makes notmuch very painful to use.  But if no one else is running into
> the problems, then I may be able to get around it by installing whatever
> fonts other people have installed.

I don't seem to have the root problem - that unknown characters cause a
delay. I get the hex-filled box immediately.

dme.
-- 
Maybe then I'll fade away and not have to face the facts.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Problems with unicode characters under emacs and Xorg

2020-11-02 Thread David Edmondson
On Monday, 2020-11-02 at 01:21:00 -08, dm-list-email-notm...@scs.stanford.edu 
wrote:

> David Edmondson  writes:
>
>> I haven't seen this. Threads with a lot of complex HTML content (lots of
>> nested tables, for example) can take a long time to render for me, but
>> that is generally interruptable.
>>
>> Could you share one of these messages, or a sufficiently similar test
>> case?
>
> Thanks for the reply.  I can send one of these emails to you privately
> if necessary, as it might contain semi-sensitive information.  However,
> I think all you need is the subject line.  For example:
>
> Subject: 
> =?UTF-8?B?RGF2aWQ6IEhvdy1UbyBIaXJlIHRoZSBCZXN0IFJlbW9kZWxpbmcgQ29udHJhY3RvciDwn5Od?=
>
> That subject line alone triggers the problem, because any search
> returning that thread triggers the problem.  When decoded, the subject
> line ends with unicode code point 0x1F4DD (MEMO).  Indeed, if I open up
> a fresh emacs, and, independent of notmuch, type "C-x 8 RET memo RET",
> it causes the emacs to hang for a minute or so.

This works fine for me, and I get an appropriate character (not just the
hex box).

According to `describe-char' it's rendered using the Symbola font. Do
you have that installed? (It's the "font-symbola" package on Debian I
believe.)

For some time I've had:

  (set-fontset-font t 'symbol "Symbola" nil 'prepend)

in ~/.emacs.el, but I just tested without and it doesn't seem to be
required.

> Arguably this is a limitation of emacs or fontconfig, or I've installed
> too many fonts on my system, or I've installed too few fonts (because
> after all that computation it just renders a box with hext digits 01F4DD
> in it instead of showing the MEMO icon).  However, the problem only
> happens with notmuch, because notmuch is the only emacs functionality I
> need that renders anything other than a very limited set of unicode
> characters.  So if there's any way either to workaround the problem, or
> to copy whatever other notmuch users are doing (is there some particular
> unicode font I should just install on my system?), I would be very
> happy.
>
> Thanks,
> David

dme.
-- 
I walk like a building, I never get wet.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: Problems with unicode characters under emacs and Xorg

2020-11-02 Thread David Edmondson
On Sunday, 2020-11-01 at 22:57:58 -08, David Mazieres wrote:

> I usually use notmuch in emacs under X windows on arch linux.  Recently,
> I've had a problem where some screens in notmuch take several minutes of
> 100% CPU time to load.  For example, I'll just open a search, and emacs
> will completely lock up (even Ctrl-G doesn't do anything) for 3 minutes
> while my fan spins and my laptop battery drains significantly.
>
> This appears to be related to the display of certain unicode characters
> in email--particularly if they are in the email subject, because then
> the whole search screen will freeze.  So far, the only workaround I've
> found is to kill -15 emacs, start it again in an xterm or urxvt with
> "emacs -nw", delete or archive the offending message, and then restart
> the Xorg emacs.  This is quite painful particularly since it's not
> always obvious which email message is causing the problem.
>
> Has anyone else experienced this problem?  Is there any way to
> workaround the problem by, for instance, defaulting to unibyte mode for
> notmuch buffers?  I do use unicode for other languages, but I guess
> wouldn't mind having to type "M-x toggle-enable-multibyte-characters" to
> get them if as a result my emacs never locked up.
>
> It's likely that this is an emacs-wide problem, but since whatever these
> characters are only show up in email, I'm hoping there are people on
> this list who know how to solve the problem or have better workarounds.

I haven't seen this. Threads with a lot of complex HTML content (lots of
nested tables, for example) can take a long time to render for me, but
that is generally interruptable.

Could you share one of these messages, or a sufficiently similar test
case?

dme.
-- 
Driving at 90 down those country lanes, singing to "Tiny Dancer".
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: emacs: `message-send-hook` being called twice

2020-08-18 Thread David Edmondson
On Tuesday, 2020-08-18 at 12:23:24 +10, Tim Quelch wrote:

> Hi all,
>
> I've been working through a bug that I've been having with org-msg
> (https://github.com/jeremy-compostella/org-msg/issues/58#issuecomment-675177076)
> and it looks like a bug in the internals of notmuch.
>
> It appears as though the `message-send-hooks` are being called twice,
> 1. In `notmuch-mua-send-common` when `notmuch-mua-send-hook` are run
> (which by default is set to `notmuch-mua-message-send-hook`, which just
> runs `message-send-hook`)
> 2. When `notmuch-mua-send-common` delegates sending of the message to
> `message-send` or `message-send-and-exit`. These functions both run 
> `message-send-hook`
>
> The specific issue this was causing in org-msg was that the message was
> being converted to html twice, causing raw html to be included in the
> sent message. This kind of issue could easily pop up again with other
> non-idempotent hook functions.
>
> I was wondering what the design descision was to set up
> `notmuch-mua-send-hook` to delegate to running `message-send-hook` when
> this is already done in `message-send`

Honestly, I don't remember. It was a long time ago.

> If this was not intentional, I don't think `notmuch-mua-send-hook` needs
> to contain `notmuch-mua-message-send-hook` by default.

I agree that it's a bug - `notmuch-mua-message-send-hook' should
probably just die.

dme.
-- 
Stop the music and go home.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v2] Emacs: Indent first header line only when indentation is turned on

2020-08-10 Thread David Edmondson
On Monday, 2020-08-10 at 17:37:57 +03, Teemu Likonen wrote:

> Previously in message-show mode message's first header line (From
> header) was always indented, even if user had turned thread
> indentation off with "<" (notmuch-show-toggle-thread-indentation)
> command.
>
> This change modifies notmuch-show-insert-headerline function so that
> it doesn't indent the first header line if notmuch-show-indent-content
> variable is nil.

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-show.el | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
>
> * 2020-08-10 11:19:10+01, David Edmondson wrote:
>>> +(insert (notmuch-show-spaces-n
>>> +(if notmuch-show-indent-content
>>> +(* notmuch-show-indent-messages-width depth)
>>> +  0))
>>
>> Couldn't you also elide the call to `notmuch-show-spaces-n'?
>
> Indeed.
>
>
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 0eb27e33..444b2a45 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -474,7 +474,10 @@ message at DEPTH in the current thread."
>;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
>;; the header paragraph as left-to-right text.
>(insert (propertize (string ?\x200e) 'invisible t)))
> -(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
> depth))
> +(insert (if notmuch-show-indent-content
> + (notmuch-show-spaces-n (* notmuch-show-indent-messages-width
> +   depth))
> +   "")
>   from
>   " ("
>   date
> -- 
> 2.20.1

dme.
-- 
I used to get mad at my school, the teachers who taught me weren't cool.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] Emacs: Indent first header line only when indentation is turned on

2020-08-10 Thread David Edmondson
On Sunday, 2020-08-09 at 22:01:44 +03, Teemu Likonen wrote:

> Previously in message-show mode message's first header line (From
> header) was always indented, even if user had turned thread
> indentation off with "<" (notmuch-show-toggle-thread-indentation)
> command.
>
> This change modifies notmuch-show-insert-headerline function so that
> it doesn't indent the first header line if notmuch-show-indent-content
> variable is nil.
> ---
>  emacs/notmuch-show.el | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 0eb27e33..2310017a 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -474,7 +474,10 @@ message at DEPTH in the current thread."
>;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
>;; the header paragraph as left-to-right text.
>(insert (propertize (string ?\x200e) 'invisible t)))
> -(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
> depth))
> +(insert (notmuch-show-spaces-n
> +  (if notmuch-show-indent-content
> +  (* notmuch-show-indent-messages-width depth)
> +0))

Couldn't you also elide the call to `notmuch-show-spaces-n'?

>   from
>   " ("
>   date
> -- 
> 2.20.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
I walk like a building, I never get wet.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v5] Emacs: Ensure left-to-right display for message headers

2020-08-10 Thread David Edmondson
On Sunday, 2020-08-09 at 23:12:28 +03, =?utf-8?Q?T=E2=80=AEomi?= Ollila wrote:

> How about this =D

Your point being that the code sanitising the displayed header could do
better?

> (Sorry how the headers might look...)
>
> From: contains U+202E (LEFT-TO-RIGHT OVERRIDE) (in =?utf-8?Q?T=E2=80=AEomi?=)
>
> https://www.fileformat.info/info/unicode/char/202e/index.htm
>
> Tomi
>
> ---
>
> (top-posting on purpose, all rest is for reference only)
>
> On Fri, Aug 07 2020, Teemu Likonen wrote:
>
>> In notmuch-show buffer insert invisible U+200E LEFT-TO-RIGHT MARK
>> character at the beginning of message header paragraph if the From
>> header contains a right-to-left character. This ensures that the
>> header paragraph is always rendered in left-to-right mode.
>>
>> See Emacs Lisp reference manual section "(elisp) Bidirectional
>> Display" for more info.
>> ---
>>  emacs/notmuch-show.el | 12 +---
>>  1 file changed, 9 insertions(+), 3 deletions(-)
>>
>>
>> As the commit description says this version inserts U+200E
>> LEFT-TO-RIGHT MARK only if the first header line (From header)
>> contains a right-to-left character.
>>
>> This version is probably friendlier to the current test files which
>> don't expect to see U+200E LEFT-TO-RIGHT MARK in the output.
>>
>>
>> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
>> index c9170466..0eb27e33 100644
>> --- a/emacs/notmuch-show.el
>> +++ b/emacs/notmuch-show.el
>> @@ -466,10 +466,16 @@ 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))
>> +(from (notmuch-sanitize
>> +   (notmuch-show-clean-address (plist-get headers :From)
>> +(when (string-match "\\cR" from)
>> +  ;; If the From header has a right-to-left character add
>> +  ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
>> +  ;; the header paragraph as left-to-right text.
>> +  (insert (propertize (string ?\x200e) 'invisible t)))
>>  (insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
>> depth))
>> -(notmuch-sanitize
>> - (notmuch-show-clean-address (plist-get headers :From)))
>> +from
>>  " ("
>>  date
>>  ") ("
>> -- 
>> 2.20.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Our President's crazy, did you hear what he said?
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v5] Emacs: Ensure left-to-right display for message headers

2020-08-07 Thread David Edmondson
On Friday, 2020-08-07 at 07:46:41 +03, Teemu Likonen wrote:

> In notmuch-show buffer insert invisible U+200E LEFT-TO-RIGHT MARK
> character at the beginning of message header paragraph if the From
> header contains a right-to-left character. This ensures that the
> header paragraph is always rendered in left-to-right mode.
>
> See Emacs Lisp reference manual section "(elisp) Bidirectional
> Display" for more info.

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-show.el | 12 +---
>  1 file changed, 9 insertions(+), 3 deletions(-)
>
>
> As the commit description says this version inserts U+200E
> LEFT-TO-RIGHT MARK only if the first header line (From header)
> contains a right-to-left character.
>
> This version is probably friendlier to the current test files which
> don't expect to see U+200E LEFT-TO-RIGHT MARK in the output.
>
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index c9170466..0eb27e33 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -466,10 +466,16 @@ 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))
> + (from (notmuch-sanitize
> +(notmuch-show-clean-address (plist-get headers :From)
> +(when (string-match "\\cR" from)
> +  ;; If the From header has a right-to-left character add
> +  ;; invisible U+200E LEFT-TO-RIGHT MARK character which forces
> +  ;; the header paragraph as left-to-right text.
> +  (insert (propertize (string ?\x200e) 'invisible t)))
>  (insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
> depth))
> - (notmuch-sanitize
> -  (notmuch-show-clean-address (plist-get headers :From)))
> + from
>   " ("
>   date
>   ") ("
> -- 
> 2.20.1

dme.
-- 
At least they're not lonely.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v3] Emacs: Force left-to-right display for message headers

2020-08-05 Thread David Edmondson
On Wednesday, 2020-08-05 at 12:40:06 +03, Teemu Likonen wrote:

> * 2020-08-05 09:45:23+01, David Edmondson wrote:
>
>> I've no idea if this is the appropriate approach to addressing this, but
>> the resulting behaviour is obviously an improvement over what happens
>> now.
>
> I think there are two options:
>
>  1. Add a string like "From: " in the beginning of notmuch-show header
> paragraph so that the paragraph always starts with left-to-right
> characters (those latin letters "From").
>
>  2. Add invisible characters that force left-to-right text for the
> paragraph. Character U+200E LEFT-TO-RIGHT MARK is meant for
> controlling exactly that.
>
> My patch implements the option 2 and...

It seems fine.

Reviewed-by: David Edmondson 

>> It would make sense to add some commentary to the code as well as the
>> commit message explaining the reason for inserting the seemingly
>> arbitrary character.
>
> ...it has at least comment
>
> ; U+200E LEFT-TO-RIGHT MARK
>
> in the code. I think that explains the purpose quite well. More verbose
> explanation could be something like this:
>
> ;; Add invisible U+200E LEFT-TO-RIGHT MARK character to force the
> ;; header paragraph as left-to-right text even if some header's
> ;; content is right-to-left.

This is much more useful to someone looking at the code (I know that the
explanation is in the commit, but when things get moved around a lot,
chasing back through commit messages can be time consuming and
difficult).

dme.
-- 
It's gettin', it's gettin', it's gettin' kinda hectic.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH v3] Emacs: Force left-to-right display for message headers

2020-08-05 Thread David Edmondson
On Tuesday, 2020-08-04 at 21:02:25 +03, Teemu Likonen wrote:

> Insert invisible U+200E LEFT-TO-RIGHT MARK at the beginning of message
> headers. It forces message headers to display as left-to-right text
> even if there are strong directional characters in header's values.
>
> See Emacs Lisp reference manual section "(elisp) Bidirectional
> Display" for more info.
> ---
>
>> This message can be applied with "git am --scissors".
>
> Sorry, it doesn't apply with "git am". Maybe PGP/MIME or
> quoted-printable encoding messed it up. This time I try with "git
> send-email".

I've no idea if this is the appropriate approach to addressing this, but
the resulting behaviour is obviously an improvement over what happens
now.

It would make sense to add some commentary to the code as well as the
commit message explaining the reason for inserting the seemingly
arbitrary character.

>  emacs/notmuch-show.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index c9170466..c45db57d 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -466,9 +466,10 @@ 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)))
> -(insert (notmuch-show-spaces-n (* notmuch-show-indent-messages-width 
> depth))
> +(insert (propertize (string ?\x200e) 'invisible t) ; U+200E 
> LEFT-TO-RIGHT MARK
> + (notmuch-show-spaces-n (* notmuch-show-indent-messages-width depth))
>   (notmuch-sanitize
>(notmuch-show-clean-address (plist-get headers :From)))
>   " ("
>   date
> -- 
> 2.20.1
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Too much information, running through my brain.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: [PATCH] emacs: notmuch-search: avoid wiping out buffer-local variables

2020-07-22 Thread David Edmondson
On Wednesday, 2020-07-22 at 08:11:32 -07, Sean Whitton wrote:
>

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch.el | 6 +-
>  1 file changed, 5 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index dd18f2e1..c97997fe 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -987,7 +987,11 @@ the configured default sort order."
>  (if no-display
>   (set-buffer buffer)
>(switch-to-buffer buffer))
> -(notmuch-search-mode)
> +;; avoid wiping out third party buffer-local variables in the case
> +;; where we're just refreshing or changing the sort order of an
> +;; existing search results buffer
> +(unless (eq major-mode 'notmuch-search-mode)
> +  (notmuch-search-mode))
>  ;; Don't track undo information for this buffer
>  (set 'buffer-undo-list t)
>  (set 'notmuch-search-query-string query)
> -- 
> 2.27.0
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
Hello? Is anybody home? Well, you don't know me, but I know you.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: notmuch.el: notmuch-search: avoid wiping out buffer-local variables

2020-07-22 Thread David Edmondson
On Tuesday, 2020-07-21 at 16:03:27 -07, Sean Whitton wrote:

> Hello,
>
> I have some code to cycle through a list of searches.  The remaining
> searches are stored in a buffer-local variable, working something like
> this (simplified):
>
> (defun spw/next-unread-group ()
>(interactive)
>(notmuch-search (car spw/more-unread-groups)
>(set (make-local-variable 'spw/more-unread-groups)
> (cdr spw/more-unread-groups
>
> However, my spw/more-unread-groups variable gets wiped out by
> notmuch-refresh-this-buffer, because the latter calls
> notmuch-search-mode, and major modes wipe out buffer-local variables.
>
> So far as I can tell that call doesn't actually have any effect when the
> mode is already notmuch-search-mode, so may I propose this patch to
> support my use case:

Seems reasonable. Could you add a comment in the code explaining that
it's to avoid clobbering third-party buffer local variables?

> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index dd18f2e1..dcbc1eb2 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -987,7 +987,8 @@ the configured default sort order."
>  (if no-display
>   (set-buffer buffer)
>(switch-to-buffer buffer))
> -(notmuch-search-mode)
> +(unless (eq major-mode 'notmuch-search-mode)
> +  (notmuch-search-mode))
>  ;; Don't track undo information for this buffer
>  (set 'buffer-undo-list t)
>  (set 'notmuch-search-query-string query)
>
> -- 
> Sean Whitton
> ___
> notmuch mailing list -- notmuch@notmuchmail.org
> To unsubscribe send an email to notmuch-le...@notmuchmail.org

dme.
-- 
What did you learn today? I learnt nothing.
___
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-le...@notmuchmail.org


Re: notmuch-emacs: Highlight the file attachment

2020-06-19 Thread David Edmondson
On Thursday, 2020-06-18 at 14:11:20 +02, Jörg Volbers wrote:

> Hi there,
>
> When showing a message with notmuch-show, I'd love to highlight 
> the file attachment part. I want to distinguish them from the 
> other mml stuff which I usually do not need to care about. Is 
> there any easy way to determine that part programmatically?

Modifying the button part based on whether the part in question is
structural or leaf should enable you to then apply different formatting.

Structural parts will, I think, always have a :content attribute that is
a list.

> Looking at the text properties in the show buffer, these parts 
> seem to be simple buttons with no special property. If notmuch 
> show would add a text property when inserting these particular 
> buttons, one could simply add a face overlay or something. Or it 
> could be wrapped in a special face.

dme.
-- 
I got a girlfriend that's better than that.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Lazily loading notmuch into Emacs

2020-06-02 Thread David Edmondson
On Monday, 2020-06-01 at 10:36:16 -07, Sean Whitton wrote:

> Hello,
>
> I don't want to put (require 'notmuch) into my Emacs init because that
> will slow down initial Emacs startup a fair bit, especially since my
> (file which is equivalent to) notmuch-config.el does quite a bit of
> processing to populate notmuch-saved-searches.
>
> So I have this:
>
> ;; Ensure notmuch does its `message-mode' configuration and that my
> ;; notmuch-config.el gets loaded before certain commands happen.  An
> ;; alternative to advising `compose-mail' and friends here would be
> ;; to remap its keys to `notmuch-mua-new-mail', but it is nice to
> ;; have things work correctly if some lisp code somewhere calls
> ;; `compose-mail' or friends
> (defun spw/load-notmuch (&rest ignore)
>   (require 'notmuch))
> (dolist (cmd '(compose-mail
>compose-mail-other-window
>compose-mail-other-frame
>notmuch-jump-search
>notmuch-hello))
>   (advice-add cmd :before #'spw/load-notmuch))
>
> (global-set-key "\C-cs" #'notmuch-search)
> (global-set-key "\C-cm" #'notmuch-jump-search)
> (global-set-key "\C-cM" #'notmuch-hello)
>
> This is not a very idiomatic way to make use of an ELPA package,
> however.  Does anyone have a better approach that does not involve
> advice-add?  I'm using the elpa-notmuch package on Debian.

I'd hoped that:

(require 'notmuch-mua)
(setq mail-user-agent 'notmuch-user-agent)

would be sufficient to get things wired up, but it doesn't seem to be.

If we fix that, would it seem more appropriate? If we get it right then
it shouldn't load any other notmuch code (including notmuch-config.el)
until you actually use one of the functions.

(None of this will configure your chosen bindings of course, you'll
still have to do that yourself.)

dme.
-- 
Everybody's got something to hide, 'cept me and my monkey.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: Respect `load-prefer-newer` when loading `notmuch-init-file'

2020-06-01 Thread David Edmondson
On Sunday, 2020-05-31 at 23:17:04 -07, Sean Whitton wrote:

> Before this change, `load-prefer-newer' was ignored.
>
> Set NOERROR and MUST-SUFFIX arguments of `load' to t, and NOSUFFIX
> argument to nil, to preserve the behaviour of the deleted `let' form.

Reviewed-by: David Edmondson 

> ---
> I've observed that the way that the code at the end of notmuch.el
> loads the user's notmuch-init-file means that the variable
> load-prefer-newer is effectively ignored: notmuch.el will always load
> notmuch-config.elc in preference to notmuch-config.el, even if the
> latter is newer than the former.  This patch should fix the problem
> without changing anything else.
>
>  emacs/notmuch.el | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index a980c7a2..5a24d8a7 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1148,8 +1148,6 @@ beginning of the line."
>  
>  ;; After provide to avoid loops if notmuch was require'd via 
> notmuch-init-file.
>  (if init-file-user ; don't load init file if the -q option was used.
> -(let ((init-file (locate-file notmuch-init-file '("/")
> -   (get-load-suffixes
> -  (if init-file (load init-file nil t t
> +(load notmuch-init-file t t nil t))
>  
>  ;;; notmuch.el ends here
> -- 
> 2.26.2
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
I went starin' out of my window, been caught doin' it once or twice.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Emacs: make browsing URLs friendlier with Helm

2020-04-25 Thread David Edmondson
On Friday, 2020-04-24 at 15:46:20 -04, Ori wrote:

> Hi,
>
> This is a fairly small point and was easy for me to locally address, and
> that in itself may be valuable in sharing, but I wondered if it would be
> worth putting a change behind a defcustom option, or depending on how this
> works with other completion frameworks, changing it altogether?
>
> The "B" shortcut calls notmuch-show-browse-urls, which calls completing-read
> with an INITIAL-INPUT of the first URL in the message. On Helm, this shows
> a near-blank list (blank unless other URLs have the first one as a
> substring). It's a nicer behavior for Helm to start off with no initial
> input, as that first URL is highlighted automatically anyway.

Keegan Carruthers-Smith posted a patch with a suggested change for this
in id:m2r1wrxin8@gmail.com. Could you try that and see if it
addresses your concerns?

That patch is now in HEAD, but I presume not yet in a release.

> Locally I simply redefine the function with a minor change (highlighted)
> after loading notmuch:
>
> (defun notmuch-show-browse-urls (&optional kill)
> "Offer to browse any URLs in the current message.
> With a prefix argument, copy the URL to the kill ring rather than
> browsing."
> (interactive "P")
> (let ((urls (notmuch-show--gather-urls))
>   (prompt (if kill "Copy URL to kill ring: " "Browse URL: "))
>   (fn (if kill #'kill-new #'browse-url)))
>   (if urls
>   (funcall fn (completing-read prompt urls))
> (message "No URLs found."
>
> For reference, in notmuch-show.el that highlighted part is:
> (completing-read prompt (cdr urls) nil nil (car urls))
>
> As I said, I'm not sure how this works with other popular completion
> alternatives like ivy and if the redefined function is better or worse with
> those. Perhaps this post is only here to be useful for other Helm users!
>
> Ori
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
Right across from where I'm standing, on the dance floor she was landing.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 4/4] emacs: Use `cl-lib' instead of deprecated `cl'

2020-04-16 Thread David Edmondson
By inspection this looks good, though I haven't tested, so...

On Wednesday, 2020-04-15 at 20:28:22 +02, Jonas Bernoulli wrote:

> Starting with Emacs 27 the old `cl' implementation is finally
> considered obsolete.  Previously its use was strongly discouraged
> at run-time but one was still allowed to use it at compile-time.
>
> For the most part the transition is very simple and boils down to
> adding the "cl-" prefix to some symbols.  A few replacements do not
> follow that simple pattern; e.g. `first' is replaced with `car',
> even though the alias `cl-first' exists, because the latter is not
> idiomatic emacs-lisp.
>
> In a few cases we start using `pcase-let' or `pcase-lambda' instead
> of renaming e.g. `first' to `car'.  That way we can remind the reader
> of the meaning of the various parts of the data that is being
> deconstructed.
>
> An obsolete `lexical-let' and a `lexical-let*' are replaced with their
> regular variants `let' and `let*' even though we do not at the same
> time enable `lexical-binding' for that file.  That is the right thing
> to do because it does not actually make a difference in those cases
> whether lexical bindings are used or not, and because this should be
> enabled in a separate commit.
>
> We need to explicitly depend on the `cl-lib' package because Emacs
> 24.1 and 24.2 lack that library.  When using these releases we end
> up using the backport from GNU Elpa.
>
> We need to explicitly require the `pcase' library because
> `pcase-dolist' was not autoloaded until Emacs 25.1.

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-company.el |   5 +-
>  emacs/notmuch-draft.el   |   2 +-
>  emacs/notmuch-hello.el   | 147 ++-
>  emacs/notmuch-jump.el|  45 +--
>  emacs/notmuch-lib.el |  18 ++---
>  emacs/notmuch-maildir-fcc.el |  35 +
>  emacs/notmuch-mua.el |  76 +-
>  emacs/notmuch-parser.el  |  18 ++---
>  emacs/notmuch-pkg.el.tmpl|   3 +-
>  emacs/notmuch-show.el| 103 
>  emacs/notmuch-tag.el |  45 ++-
>  emacs/notmuch-tree.el|  20 ++---
>  emacs/notmuch.el |  62 +++
>  test/test-lib.el |   2 +-
>  14 files changed, 292 insertions(+), 289 deletions(-)
>
> diff --git a/emacs/notmuch-company.el b/emacs/notmuch-company.el
> index 3e12e7a9..ac998f9b 100644
> --- a/emacs/notmuch-company.el
> +++ b/emacs/notmuch-company.el
> @@ -27,7 +27,8 @@
>  
>  ;;; Code:
>  
> -(eval-when-compile (require 'cl))
> +(eval-when-compile (require 'cl-lib))
> +
>  (require 'notmuch-lib)
>  
>  (defvar notmuch-company-last-prefix nil)
> @@ -65,7 +66,7 @@ (defun notmuch-company (command &optional arg &rest _ignore)
>(require 'company)
>(let ((case-fold-search t)
>   (completion-ignore-case t))
> -(case command
> +(cl-case command
>(interactive (company-begin-backend 'notmuch-company))
>(prefix (and (derived-mode-p 'message-mode)
>  (looking-back (concat 
> notmuch-address-completion-headers-regexp ".*")
> diff --git a/emacs/notmuch-draft.el b/emacs/notmuch-draft.el
> index e22e0d16..504b33be 100644
> --- a/emacs/notmuch-draft.el
> +++ b/emacs/notmuch-draft.el
> @@ -152,7 +152,7 @@ (defun notmuch-draft--query-encryption ()
>"Checks if we should save a message that should be encrypted.
>  
>  `notmuch-draft-save-plaintext' controls the behaviour."
> -  (case notmuch-draft-save-plaintext
> +  (cl-case notmuch-draft-save-plaintext
>   ((ask)
>(unless (yes-or-no-p "(Customize `notmuch-draft-save-plaintext' to 
> avoid this warning)
>  This message contains mml tags that suggest it is intended to be encrypted.
> diff --git a/emacs/notmuch-hello.el b/emacs/notmuch-hello.el
> index aff8beb5..74996636 100644
> --- a/emacs/notmuch-hello.el
> +++ b/emacs/notmuch-hello.el
> @@ -21,7 +21,8 @@
>  
>  ;;; Code:
>  
> -(eval-when-compile (require 'cl))
> +(eval-when-compile (require 'cl-lib))
> +
>  (require 'widget)
>  (require 'wid-edit) ; For `widget-forward'.
>  
> @@ -44,17 +45,19 @@ (defun notmuch-saved-search-get (saved-search field)
> ((keywordp (car saved-search))
>  (plist-get saved-search field))
> ;; It is not a plist so it is an old-style entry.
> -   ((consp (cdr saved-search)) ;; It is a list (NAME QUERY COUNT-QUERY)
> -(case field
> -  (:name (first saved-search))
> -  (:query (second saved-search))
> -   

Re: [PATCH] emacs: introduce notmuch-search-by-tag

2020-04-14 Thread David Edmondson
On Monday, 2020-04-13 at 22:10:50 +02, Keegan Carruthers-Smith wrote:

> This is like notmuch-search-filter-by-tag, but creates a new search
> rather than filtering the current search. We add this to
> notmuch-common-keymap since this can be used by many contexts. We bind
> to the key "t", which is the same key used by
> notmuch-search-filter-by-tag in notmuch-search-mode-map. This is done
> intentionally since the keybinding for notmuch-search-mode-map can be
> seen as a specialization of creating a new search.
>
> This change was motivated for use in "notmuch-hello". It is a more
> convenient way to search a tag than expanding the list of all tags. I
> also noticed many saved searches people use are simply tags.

Reviewed-by: David Edmondson 

> ---
>  devel/emacs-keybindings.org | 2 +-
>  emacs/notmuch-lib.el| 1 +
>  emacs/notmuch.el| 6 ++
>  3 files changed, 8 insertions(+), 1 deletion(-)
>
> diff --git a/devel/emacs-keybindings.org b/devel/emacs-keybindings.org
> index 464b9467..65dfe0eb 100644
> --- a/devel/emacs-keybindings.org
> +++ b/devel/emacs-keybindings.org
> @@ -20,7 +20,7 @@
>  | q | notmuch-bury-or-kill-this-buffer   | 
> notmuch-bury-or-kill-this-buffer  | 
> notmuch-bury-or-kill-this-buffer|
>  | r | notmuch-search-reply-to-thread-sender  | 
> notmuch-show-reply-sender | 
> notmuch-show-reply-sender   |
>  | s | notmuch-search | notmuch-search
> | notmuch-search  |
> -| t | notmuch-search-filter-by-tag   | toggle-truncate-lines 
> | |
> +| t | notmuch-search-filter-by-tag   | toggle-truncate-lines 
> | notmuch-search-by-tag   |
>  | u ||   
> | |
>  | v ||   
> | notmuch-show-view-all-mime-parts|
>  | w || 
> notmuch-show-save-attachments | 
> notmuch-show-save-attachments   |
> diff --git a/emacs/notmuch-lib.el b/emacs/notmuch-lib.el
> index 73b165e4..e085a06b 100644
> --- a/emacs/notmuch-lib.el
> +++ b/emacs/notmuch-lib.el
> @@ -153,6 +153,7 @@ For example, if you wanted to remove an \"inbox\" tag and 
> add an
>  (define-key map "?" 'notmuch-help)
>  (define-key map "q" 'notmuch-bury-or-kill-this-buffer)
>  (define-key map "s" 'notmuch-search)
> +(define-key map "t" 'notmuch-search-by-tag)
>  (define-key map "z" 'notmuch-tree)
>  (define-key map "u" 'notmuch-unthreaded)
>  (define-key map "m" 'notmuch-mua-new-mail)
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index f4789b4f..f5f03244 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -1077,6 +1077,12 @@ current search results AND that are tagged with the 
> given tag."
> (list (notmuch-select-tag-with-completion "Filter by tag: " 
> notmuch-search-query-string)))
>(notmuch-search (concat notmuch-search-query-string " and tag:" tag) 
> notmuch-search-oldest-first))
>  
> +(defun notmuch-search-by-tag (tag)
> +  "Display threads matching TAG in a notmuch-search buffer."
> +  (interactive
> +   (list (notmuch-select-tag-with-completion "Notmuch search tag: ")))
> +  (notmuch-search (concat "tag:" tag)))
> +
>  ;;;###autoload
>  (defun notmuch ()
>"Run notmuch and display saved searches, known tags, etc."
> -- 
> 2.26.0
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
Why stay in college? Why go to night school?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: use def instead of initial-input for notmuch-show-browse-urls

2020-04-14 Thread David Edmondson
On Monday, 2020-04-13 at 21:58:19 +02, Keegan Carruthers-Smith wrote:

> This is the non-deprecated way to use completing-read. Additionally
> the old use was broken when using ivy for completing-read. For user's
> using completing-read-default they won't see the default URL now, but
> if they hit enter it will be visited. Alternatively they can select
> it with M-n.
>
> From the completing-read documentation for initial-input:
>
>  This feature is deprecated--it is best to pass nil for INITIAL-INPUT
>  and supply the default value DEF instead.  The user can yank the
>  default value into the minibuffer easily using M-n.
>
> Additionally collection is now all urls, rather than all but the
> first. I'm not sure why "(cdr urls)" was previously done.

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-show.el | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
> index 214e279f..079281c3 100644
> --- a/emacs/notmuch-show.el
> +++ b/emacs/notmuch-show.el
> @@ -2559,7 +2559,7 @@ browsing."
>   (prompt (if kill "Copy URL to kill ring: " "Browse URL: "))
>   (fn (if kill #'kill-new #'browse-url)))
>  (if urls
> - (funcall fn (completing-read prompt (cdr urls) nil nil (car urls)))
> + (funcall fn (completing-read prompt urls nil nil nil nil (car urls)))
>(message "No URLs found."
>  
>  (provide 'notmuch-show)
> -- 
> 2.26.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
I used to worry, thought I was goin' mad in a hurry.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: notmuch-crypto.el: "‘notmuch-show-get-message-id’ is not known to be defined"

2020-03-18 Thread David Edmondson
On Wednesday, 2020-03-18 at 10:49:14 +01, Örjan Ekeberg wrote:

> Daniel Kahn Gillmor  writes:
>
>> When building the current version of notmuch on debian testing/unstable,
>> i see the following warning:
>>
>> ```
>> EMACS emacs/notmuch-crypto.elc
>>
>> In end of data:
>> emacs/notmuch-crypto.el:266:1:Warning: the function
>> ‘notmuch-show-get-message-id’ is not known to be defined.
>> ```
>>
>> No part of the test suite fails so i assume it's not a problem, but
>> having spurious warnings makes it harder to notice real warnings in the
>> future.
>>
>> I don't know what the warning means exactly, but maybe someone who is
>> better with elisp than i am could take a look at it and try to resolve
>> it?
>
> Adding this line in notmuch-crypto.el solves this:
>
> (declare-function notmuch-show-get-message-id "notmuch-show" (&optional bare))
>
> As a matter of style, I am not sure where to put it.  Normally, these
> declarations are put in the beginning of the file; right after the
> require-statements.  In notmuch-crypto.el, however, the only other
> declaration is put just in front of where the function is called.

As you say, we normally gather them near to the top of the file.

dme.
-- 
My girl Friday, she no square.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 0/7] Port notmuch-show's x/X bindings to notmuch-tree

2020-02-21 Thread David Edmondson
On Friday, 2020-02-21 at 09:06:46 -08, William Casarin wrote:

> Daniel Kahn Gillmor  writes:
>
>> On Sat 2019-12-28 10:01:17 -0500, William Casarin wrote:
>>> These patches bring notmuch-tree more in line with the user experience
>>> of notmuch-show by adding the x/X bindings.
>>
>> It looks like this series has been reviewed by dme, and is presumably
>> approved by him, with the exception of patch 3/7, which
>> id:m25zhyxasu@dme.org suggests some improvement on.
>>
>> William, would you be up for doing one last re-spin of this series to
>> address dme's comments?  it'd be nice to land this series unless someone
>> raises objections.
>
> I was planning on it but it fell by the wayside. The only comment was
> just a naming thing, perhaps we can just pull this and rename it in a
> future patch?

That would be fine with me.

> I could do a whole new series but I feel like that is overkill.

dme.
-- 
You make me feel like a natural woman.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Identical messages in multiple folders or email accounts

2020-01-06 Thread David Edmondson
On Monday, 2020-01-06 at 06:04:37 -07, Nicolas Bock wrote:

> Hi,
>
> In the case of identical messages in multiple folders, is it possible
> to tag a specific copy?

No.

> All my attempts to limit `notmuch tag` and `notmuch search` to a
> particular folder have failed so far.
>
> $ notmuch tag +test-tag
> id:218107fa-7705-67a9-a5f5-580260a94...@nwra.com and
> folder:acct_2/Archives/2019
> $ notmuch search --output=files tag:test-tag and 
> folder:acct_2/Archives/2019
> 
> /home/nbock/Mail/acct_1/[Gmail]/Trash/cur/887174bc-2da7-11ea-ba39-28f10e4fd9ec,U=14852:2,S
> 
> /home/nbock/Mail/acct_2/Archives/2019/cur/1577989597.767223_920.rubberducky,U=15165:2,S
>
> Best,
>
> Nick
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
If the girls start moving the boys will start moving.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: don't start processes stopped

2020-01-03 Thread David Edmondson
On Friday, 2020-01-03 at 09:04:00 -08, Steven Allen wrote:

> It causes this function to fail with:
>
> let: Wrong type argument: null, t
>
> Support for this was removed from Emacs in April
> 2019 (5c5e309527e6b582e2c04b83e7af45f3144863ac) because it never
> worked correctly (apparently).
>
> This also shouldn't be necessary as sentinels will not be called
> unless emacs is idle or waiting for input. Therefore, the
> `process-put' calls immediately following the `make-process' call
> should always complete before the sentinel is first called.

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-crypto.el | 9 ++---
>  1 file changed, 2 insertions(+), 7 deletions(-)
>
> diff --git a/emacs/notmuch-crypto.el b/emacs/notmuch-crypto.el
> index f4585d5e..4035ee37 100644
> --- a/emacs/notmuch-crypto.el
> +++ b/emacs/notmuch-crypto.el
> @@ -222,16 +222,11 @@ corresponding key when the status button is pressed."
>:buffer buffer
>:stderr buffer
>:command (list notmuch-crypto-gpg-program 
> "--recv-keys" keyid)
> -  :sentinel #'notmuch-crypto--async-key-sentinel
> -  ;; Create the process stopped so that
> -  ;; we have time to store the key id,
> -  ;; etc. on it.
> -  :stop t)))
> +  :sentinel 
> #'notmuch-crypto--async-key-sentinel)))
>   (process-put p :gpg-key-id keyid)
>   (process-put p :notmuch-show-buffer (current-buffer))
>   (process-put p :notmuch-show-point (point))
> - (message "Getting the GPG key %s asynchronously..." keyid)
> - (continue-process p)))
> + (message "Getting the GPG key %s asynchronously..." keyid)))
>  
>(let ((window (display-buffer buffer)))
>   (with-selected-window window
> -- 
> 2.24.1
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
We can dance if we want to, we can leave your friends behind.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 7/7] emacs/tree: add x/X bindings

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:24 -05, William Casarin wrote:

> Add x and X binds to notmuch-tree for functionally that we have in
> notmuch-show.
>
> The notmuch-tree-quit binding is somewhat redundant, since it is
> handled by notmuch-bury-or-kill-this-buffer which is bound to q.
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index e9c0433c..987cc81e 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -277,7 +277,8 @@ FUNC."
>  ;; The main tree view bindings
>  (define-key map (kbd "RET") 'notmuch-tree-show-message)
>  (define-key map [mouse-1] 'notmuch-tree-show-message)
> -(define-key map "x" 'notmuch-tree-quit)
> +(define-key map "x" 'notmuch-tree-archive-message-then-next-or-exit)
> +(define-key map "X" 'notmuch-tree-archive-thread-then-exit)
>  (define-key map "A" 'notmuch-tree-archive-thread)
>  (define-key map "a" 'notmuch-tree-archive-message-then-next)
>  (define-key map "z" 'notmuch-tree-to-tree)
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
You know your green from your red.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 6/7] emacs/tree: add notmuch-tree-archive-thread-then-exit

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:23 -05, William Casarin wrote:

> This is the notmuch-tree version of
> notmuch-show-archive-thread-then-exit
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 6 ++
>  1 file changed, 6 insertions(+)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index cdf68ed4..e9c0433c 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -563,6 +563,12 @@ message will be \"unarchived\", i.e. the tag changes in
>(notmuch-tree-archive-message unarchive)
>(notmuch-tree-next-matching-message))
>  
> +(defun notmuch-tree-archive-thread-then-exit ()
> +  "Archive all messages in the current buffer, then exit notmuch-tree."
> +  (interactive)
> +  (notmuch-tree-archive-thread)
> +  (notmuch-tree-quit t))
> +
>  (defun notmuch-tree-archive-message-then-next-or-exit ()
>"Archive current message, then show next open message in current thread.
>  
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
Here I am, a rabbit-hearted girl.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 5/7] emacs/tree: add notmuch-tree-archive-message-than-next-or-exit

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:22 -05, William Casarin wrote:

> This is the notmuch-tree version of
> notmuch-show-archive-message-than-next-or-exit.
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 30 --
>  1 file changed, 20 insertions(+), 10 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index f66219c5..cdf68ed4 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -563,6 +563,15 @@ message will be \"unarchived\", i.e. the tag changes in
>(notmuch-tree-archive-message unarchive)
>(notmuch-tree-next-matching-message))
>  
> +(defun notmuch-tree-archive-message-then-next-or-exit ()
> +  "Archive current message, then show next open message in current thread.
> +
> +If at the last open message in the current thread, then exit back
> +to search results."
> +  (interactive)
> +  (notmuch-tree-archive-message)
> +  (notmuch-tree-next-matching-message t))
> +
>  (defun notmuch-tree-next-message ()
>"Move to next message."
>(interactive)
> @@ -589,23 +598,24 @@ nil otherwise."
>(forward-line dir))
>  (not (funcall eobfn
>  
> -(defun notmuch-tree-matching-message (&optional prev)
> +(defun notmuch-tree-matching-message (&optional prev pop-at-end)
>"Move to the next or previous matching message"
>(interactive "P")
>(forward-line (if prev -1 nil))
> -  (notmuch-tree-goto-matching-message prev)
> -  (when (window-live-p notmuch-tree-message-window)
> -(notmuch-tree-show-message-in)))
> +  (if (and (not (notmuch-tree-goto-matching-message prev)) pop-at-end)
> +  (notmuch-tree-quit pop-at-end)
> +(when (window-live-p notmuch-tree-message-window)
> +  (notmuch-tree-show-message-in
>  
> -(defun notmuch-tree-prev-matching-message ()
> +(defun notmuch-tree-prev-matching-message (&optional pop-at-end)
>"Move to previous matching message."
> -  (interactive)
> -  (notmuch-tree-matching-message t))
> +  (interactive "P")
> +  (notmuch-tree-matching-message t pop-at-end))
>  
> -(defun notmuch-tree-next-matching-message ()
> +(defun notmuch-tree-next-matching-message (&optional pop-at-end)
>"Move to next matching message."
> -  (interactive)
> -  (notmuch-tree-matching-message))
> +  (interactive "P")
> +  (notmuch-tree-matching-message nil pop-at-end))
>  
>  (defun notmuch-tree-refresh-view ()
>"Refresh view."
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
I know a man called Sylvester, him have to wear a bullet proof vest y'all.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 4/7] emacs/tree: add kill-both prefix argument to notmuch-tree-quit

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:21 -05, William Casarin wrote:

> This allows us to close both windows at the same time.
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 25d84f45..f66219c5 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -530,10 +530,10 @@ Shows in split pane or whole window according to value 
> of
>(when (notmuch-tree-scroll-message-window)
>  (notmuch-tree-next-matching-message)))
>  
> -(defun notmuch-tree-quit ()
> +(defun notmuch-tree-quit (&optional kill-both)
>"Close the split view or exit tree."
> -  (interactive)
> -  (unless (notmuch-tree-close-message-window)
> +  (interactive "P")
> +  (when (or (not (notmuch-tree-close-message-window)) kill-both)
>  (kill-buffer (current-buffer
>  
>  (defun notmuch-tree-close-message-window ()
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
Oh there ain't no way to say I love you more.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 3/7] emacs/tree: add notmuch-tree-matching-message

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:20 -05, William Casarin wrote:

> This functions removes some duplicate logic between
> notmuch-tree-{next,prev}-matching-message
>
> We do this because we will be adding some additional logic similar to
> the notmuch-show-next-open-message function, and it will help if this
> logic is all in one place.
>
> Signed-off-by: William Casarin 
> ---
>  emacs/notmuch-tree.el | 18 ++
>  1 file changed, 10 insertions(+), 8 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 18fdb1c0..25d84f45 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -589,21 +589,23 @@ nil otherwise."
>(forward-line dir))
>  (not (funcall eobfn
>  
> +(defun notmuch-tree-matching-message (&optional prev)
> +  "Move to the next or previous matching message"
> +  (interactive "P")
> +  (forward-line (if prev -1 nil))
> +  (notmuch-tree-goto-matching-message prev)
> +  (when (window-live-p notmuch-tree-message-window)
> +(notmuch-tree-show-message-in)))
> +

The naming is getting a bit contorted here.

How about renaming the existing `notmuch-tree-goto-matching-message' to
something internal, like `notmuch-tree--goto-matching-message-1' and
then the new `notmuch-tree-matching-message' to
`notmuch-tree-goto-matching-message', to make it clear that the new
function moves to a different message.

>  (defun notmuch-tree-prev-matching-message ()
>"Move to previous matching message."
>(interactive)
> -  (forward-line -1)
> -  (notmuch-tree-goto-matching-message t)
> -  (when (window-live-p notmuch-tree-message-window)
> -(notmuch-tree-show-message-in)))
> +  (notmuch-tree-matching-message t))
>  
>  (defun notmuch-tree-next-matching-message ()
>"Move to next matching message."
>(interactive)
> -  (forward-line)
> -  (notmuch-tree-goto-matching-message)
> -  (when (window-live-p notmuch-tree-message-window)
> -(notmuch-tree-show-message-in)))
> +  (notmuch-tree-matching-message))
>  
>  (defun notmuch-tree-refresh-view ()
>"Refresh view."
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
I'm not living in the real world, no more, no more.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 2/7] emacs/tree: add notmuch-tree-goto-matching-message

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:19 -05, William Casarin wrote:

> This function captures some common logic when jumping to matching
> messages in notmuch-tree mode.
>
> We also add a new return value (t or nil), that indicates if there was
> a next matching message in the thread to show.
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 18 ++
>  1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index d262ba26..18fdb1c0 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -577,12 +577,23 @@ message will be \"unarchived\", i.e. the tag changes in
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> +(defun notmuch-tree-goto-matching-message (&optional prev)
> +  "Move to the next or previous matching message.
> +
> +Returns t if there was a next matching message in the thread to show,
> +nil otherwise."
> +  (let ((dir (if prev -1 nil))

You don't need this final `nil', but it's a real nit ;-)

> + (eobfn (if prev #'bobp #'eobp)))
> +(while (and (not (funcall eobfn))
> + (not (notmuch-tree-get-match)))
> +  (forward-line dir))
> +(not (funcall eobfn
> +
>  (defun notmuch-tree-prev-matching-message ()
>"Move to previous matching message."
>(interactive)
>(forward-line -1)
> -  (while (and (not (bobp)) (not (notmuch-tree-get-match)))
> -(forward-line -1))
> +  (notmuch-tree-goto-matching-message t)
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> @@ -590,8 +601,7 @@ message will be \"unarchived\", i.e. the tag changes in
>"Move to next matching message."
>(interactive)
>(forward-line)
> -  (while (and (not (eobp)) (not (notmuch-tree-get-match)))
> -(forward-line))
> +  (notmuch-tree-goto-matching-message)
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> -- 
> 2.24.0

dme.
-- 
You bring light in.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v3 1/7] emacs/tree: return true if a thread was found in next-thread

2019-12-30 Thread David Edmondson
On Saturday, 2019-12-28 at 10:01:18 -05, William Casarin wrote:

> This will allow us to pop back to parent buffers when there are no
> more threads to jump to.
>
> Signed-off-by: William Casarin 

Reviewed-by: David Edmondson 

> ---
>  emacs/notmuch-tree.el | 5 -
>  1 file changed, 4 insertions(+), 1 deletion(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index c00315e8..d262ba26 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -620,10 +620,13 @@ message will be \"unarchived\", i.e. the tag changes in
>(notmuch-tree-thread-top))
>  
>  (defun notmuch-tree-next-thread ()
> +  "Get the next thread in the current tree. Returns t if a thread was
> +found or nil if not."
>(interactive)
>(forward-line 1)
>(while (not (or (notmuch-tree-get-prop :first) (eobp)))
> -(forward-line 1)))
> +(forward-line 1))
> +  (not (eobp)))
>  
>  (defun notmuch-tree-thread-mapcar (function)
>"Iterate through all messages in the current thread
> -- 
> 2.24.0

dme.
-- 
Why stay in college? Why go to night school?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 1/2] legacy-display: accept text/plain legacy display parts

2019-12-24 Thread David Edmondson
On Tuesday, 2019-12-24 at 10:54:46 -05, Daniel Kahn Gillmor wrote:

> On Tue 2019-12-24 10:59:09 +0000, David Edmondson wrote:
>> Patch looks good, though I would quite like there to be a comment in the
>> code. Something simple like:
>>
>> /* text/rfc822-headers was replaced by text/plain as the MIME type for
>> “Legacy Display” parts - we allow either. */
>
> I have no objection to having this comment in the code (though i think
> i'd replace U+201C LEFT DOUBLE QUOTATION MARK and U+201D RIGHT DOUBLE
> QUOTATION MARK with U+0022 QUOTATION MARK.  i don't think we have any
> non-ASCII text in our C source at the moment, and this doesn't seem like
> the right place to introduce it.

Agreed.

> Since the code will be read in the future, not the past, i think the
> right comment might be:
>
>  /* Early implementations that generated "Legacy Display" parts used
> Content-Type: text/rfc822-headers, but text/plain is more widely
> rendered, so it is now the standard choice.  We accept either as a
> Legacy Display part. */

Looks good to me, thank you.

> Bremner, if you are considering a merge, and want to inject this comment
> yourself, that's fine with me.  let me know if you want me to send
> another revision instead.
>
> --dkg

dme.
-- 
And the sign said: long haired freaky people need not apply.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 1/2] legacy-display: accept text/plain legacy display parts

2019-12-24 Thread David Edmondson
On Monday, 2019-12-23 at 12:39:26 -05, Daniel Kahn Gillmor wrote:

> https://www.ietf.org/id/draft-autocrypt-lamps-protected-headers-02.html
> Makes it clear that the "Legacy Display" part of an encrypted message
> with protected headers can (and indeed, should) be of content-type
> text/plain, though some clients still generate the Legacy Display part
> as content-type text/rfc822-headers.  Notmuch should recognize the
> part whichever of the two content-types it uses.
>
> See also discussion in
> https://github.com/autocrypt/protected-headers/issues/23 for why the
> community of implementers is moving in the direction of text/plain.
>
> Signed-off-by: Daniel Kahn Gillmor 
> ---
>  util/repair.c | 6 --
>  1 file changed, 4 insertions(+), 2 deletions(-)
>
> diff --git a/util/repair.c b/util/repair.c
> index 9fba97b7..4385d16f 100644
> --- a/util/repair.c
> +++ b/util/repair.c
> @@ -49,8 +49,10 @@ _notmuch_crypto_payload_has_legacy_display (GMimeObject 
> *payload)
>  if (g_mime_multipart_get_count (mpayload) != 2)
>   return false;
>  first = g_mime_multipart_get_part (mpayload, 0);
> -if (! g_mime_content_type_is_type (g_mime_object_get_content_type 
> (first),
> -"text", "rfc822-headers"))
> +if (! (g_mime_content_type_is_type (g_mime_object_get_content_type 
> (first),
> + "text", "plain") ||
> +g_mime_content_type_is_type (g_mime_object_get_content_type (first),
> + "text", "rfc822-headers")))

Patch looks good, though I would quite like there to be a comment in the
code. Something simple like:

/* text/rfc822-headers was replaced by text/plain as the MIME type for
“Legacy Display” parts - we allow either. */

>   return false;
>  protected_header_parameter = g_mime_object_get_content_type_parameter 
> (first, "protected-headers");
>  if ((! protected_header_parameter) || strcmp 
> (protected_header_parameter, "v1"))
> -- 
> 2.24.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
It's alright, we told you what to dream.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 0/2] Limit attachment check to stop before forwarded message

2019-12-13 Thread David Edmondson
On Friday, 2019-12-13 at 00:35:34 +01, ekeb...@kth.se wrote:

> From: Örjan Ekeberg 
>
> This is a simple patch to notmuch-mua-attachment-check to make it stop
> searching for mathing "attachment"-words when reaching a forwarded
> message (or anything starting with "\n<#").  This avoids the false
> warnings that always occur when forwarding messages originating from
> MS-Exchange, since they contain a header "MS-Has-Attach:".
>
> Örjan Ekeberg (2):
>   emacs: limit search for attachment to stop at first mime-part
>   test: extend test of attachment warnings
>
>  emacs/notmuch-mua.el  | 25 ++---
>  test/emacs-attachment-warnings.el | 12 
>  2 files changed, 26 insertions(+), 11 deletions(-)

Looks good - thanks for doing this.

(Apologies for the resend - hit 'r' not 'R' the first time.)

dme.
-- 
I'd come on over but I haven't got a raincoat.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: message.el and browse-url.el interaction [was: Re: BUG: notmuch-emacs-mua wrong signing MML placement]

2019-12-13 Thread David Edmondson
On Friday, 2019-12-13 at 09:33:11 +02, Tomi Ollila wrote:

> Small update from my front -- looked message.el and (message-setup-1)
> there in particular, and then tested the following code:
>
> (with-demoted-errors
>  (require 'notmuch)
>  (let ((message-signature-setup-hook message-signature-setup-hook))
>(add-hook 'message-signature-setup-hook
>  (lambda () (message-goto-body) (insert "testbody")
> (if (/= (point) (line-beginning-position))
>   (newline
>(notmuch-mua-mail "fred" nil nil nil
>   (notmuch-mua-get-switch-function))
> ))
>
> This has moderate chance of working, so I'll have to think it a bit
> further (and clean up the code =D)...

This seems like liberal abuse of `message-signature-setup-hook' :-)

It's also message.el specific, which may not matter. The `compose-mail'
argument approach should in principle work with all mail-user-agent
settings.


dme.
-- 
Why stay in college? Why go to night school?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: Add notmuch-wash-citation-lines-elided-min and use it

2019-12-12 Thread David Edmondson
When collapsing citations, if the collapsed region is less than
`notmuch-wash-citation-lines-elided-min' lines long, don't bother
collapsing it and simply show all of the lines.
---
 emacs/notmuch-wash.el | 9 -
 1 file changed, 8 insertions(+), 1 deletion(-)

diff --git a/emacs/notmuch-wash.el b/emacs/notmuch-wash.el
index 54108d93..556fd2ab 100644
--- a/emacs/notmuch-wash.el
+++ b/emacs/notmuch-wash.el
@@ -117,6 +117,13 @@ collapse the remaining lines into a button."
   :type 'integer
   :group 'notmuch-wash)
 
+(defcustom notmuch-wash-citation-lines-elided-min 1
+  "When collapsing a citation would remove less than
+`notmuch-wash-citation-lines-elided-min' lines, no collapsing
+takes place."
+  :type 'integer
+  :group 'notmuch-wash)
+
 (defcustom notmuch-wash-wrap-lines-length nil
   "Wrap line after at most this many characters.
 
@@ -241,7 +248,7 @@ that PREFIX should not include a newline."
   (overlay-put (make-overlay cite-start cite-end) 'face 
'notmuch-wash-cited-text)
   (when (> cite-lines (+ notmuch-wash-citation-lines-prefix
 notmuch-wash-citation-lines-suffix
-1))
+notmuch-wash-citation-lines-elided-min))
(goto-char cite-start)
(forward-line notmuch-wash-citation-lines-prefix)
(let ((hidden-start (point-marker)))
-- 
2.24.0

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


Re: version 4: Retrieve GPG keys asynchronously.

2019-12-12 Thread David Edmondson
On Wednesday, 2019-09-11 at 21:32:56 -04, Daniel Kahn Gillmor wrote:

> In id:87blw1rldy@tethera.net, bremner identified two of my edits
> breaking dme's series that permits asynchronous retrieval of OpenPGP
> keys.
>
> This is a revision of that series that should apply to the current
> master, taking into account my earlier fixes.
>
> dme, if you could review i would appreciate it.  I think i've done
> what you would have done, but as usual my elisp skills are weaker than
> yours, so i welcome your feedback.  The test suite passes for me at
> least :)

The rebased changes look good to me. Sorry for taking so long to review.

dme.
-- 
At least they're not lonely.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


message.el and browse-url.el interaction [was: Re: BUG: notmuch-emacs-mua wrong signing MML placement]

2019-12-12 Thread David Edmondson
On Wednesday, 2019-12-11 at 13:55:16 -05, Robbie Harwood wrote:

> My emacs config contains `(add-hook 'message-setup-hook
> 'mml-secure-sign-pgpmime)` as recommended in the emacstips
> https://notmuchmail.org/emacstips/#index14h2
>
> However, when I run (something like):
>
> notmuch-emacs-mua 'mailto:testto?body=testbody'
>
> I get an email in which the requested body contents appear *before* the
> signing MML.  If I understand correctly how this all fits together, that
> won't do the right thing - but at any rate, it's unexpected.

This is an unfortunate interaction between message.el and browse-url.el
and isn't specific to notmuch or notmuch-emacs-mua.

You can see the same behaviour in “emacs -Q -q” if you execute:

(progn
 (add-hook 'message-setup-hook 'mml-secure-sign-pgpmime)
 (browse-url-mail "mailto:fred?body=testbody";))

Given that, it's not something that we should be fixing in notmuch
itself, as it's an emacs bug.

The problem is that `browse-url-mail' always inserts the body after the
header separator, which in this case happens after
`mml-secure-sign-pgpmime' has already inserted the MML header.

Having `browse-url-mail' insert the body at the end of the message would
work for this case, but would presumably make a mess of situations where
someone inserts their signature block via `message-setup-hook'.

Perhaps `browse-url-mail' should skip past any MML headers before
inserting the body? That's a bit messy, as browse-url.el currently
doesn't know anything about MML.

The nicest fix would perhaps be to have `compose-mail' accept the
initial body as a parameter, which would eventually flow into the
relevant code in message.el which could do the right thing (which I
think would just be to skip past MML headers before inserting the body).

Any advice from emacs-devel on how to move forward? I'm happy to produce
a patch for whatever solution is considered most appropriate.

dme.
-- 
If the girls start moving the boys will start moving.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: script to move messages according to tags

2019-12-11 Thread David Edmondson
On Wednesday, 2019-12-11 at 16:28:20 +01, Alan Schmitt wrote:

> I do have one small question: how do you deal with mails that have
> duplicates? For instance, when I send a mail to a mailing list, I end
> up with both the sent email and the one I later receive from the
> list. If I tag the send one with deleted (no need to keep it), won't I
> run the risk to delete both mails?

If you have the id of a message you can get a list of all of the
corresponding files with:
  notmuch search --exclude=false --output=files $id

How you decide to deal with multiple results is really up to you - in my
case I move/delete all of them (except that I don't actually delete
anything).

dme.
-- 
Our President's crazy, did you hear what he said?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: moving the config into the database [was: Re: [PATCH] Display extra headers for emacs-mua - db config option]

2019-12-11 Thread David Edmondson
On Wednesday, 2019-12-11 at 10:00:07 -04, David Bremner wrote:

> David Edmondson  writes:
>
>> It seems that only “notmuch new” is currently prepared to create a new
>> database, but it will also import all of my email before I have a chance
>> to set the above parameters.
>>
>> It seems that the obvious answer is “notmuch config” will create a
>> database if necessary. Is that the plan?
>
> Wouldn't it make sense to have "notmuch setup" do this?

Oh, yes, of course. I had forgotten that existed :-)

dme.
-- 
Tell her I'll be waiting, in the usual place.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: moving the config into the database [was: Re: [PATCH] Display extra headers for emacs-mua - db config option]

2019-12-11 Thread David Edmondson
On Tuesday, 2019-12-10 at 08:11:56 -08, Jameson Graef Rollins wrote:

> Fwiw I support dkg's idea to store the config in the database itself.  I
> think that's a clean simplification that makes a lot of sense.

I'm not inherently against this, but I'm unsure exactly how it would
work.

For example, I set new.tags and new.ignore in my current
.notmuch-config. If they move into the database, how will I set them
before I have a database?

It seems that only “notmuch new” is currently prepared to create a new
database, but it will also import all of my email before I have a chance
to set the above parameters.

It seems that the obvious answer is “notmuch config” will create a
database if necessary. Is that the plan?

dme.
-- 
They like the smell of it in Hollywood.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


rfc: notmuch-status.el - notmuch status reporting

2019-12-05 Thread David Edmondson
I've been using something like this code for a few years, so I figured
that some other people might also want it.

It's intended as an in-emacs mail notifier, though in most cases I don't
actually have the “notifier” part running, I just use a key sequence to
query the state.

The idea is to layer on top of the existing `notmuch-saved-searches' as
a set of queries that you find interesting. When combined with
`notmuch-jump' it provides, I think, a quick way of seeing the state of
queries that you care about and then jumping to the corresponding
messages.

Hopefully the explanatory text in the file itself is sufficient for
someone to use it.

I am, of course, open to suggestions and improvements.

If it's of interest to others I'm happy to submit a patch to have it
added to notmuch, perhaps after we've discussed it a bit here.


notmuch-status.el
Description: application/emacs-lisp

dme.
-- 
If I could buy my reasoning, I'd pay to lose.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later

2019-12-04 Thread David Edmondson
Gregor, does Stefan's change fix your problem?

dme.
-- 
So tap at my window, maybe I might let you in.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later

2019-12-03 Thread David Edmondson
On Tuesday, 2019-12-03 at 15:39:47 -05, Stefan Monnier wrote:

>> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require
>> 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header)
>> (message \"%s\" message-sendmail-envelope-from))"
>> nil
>> disaster-area ~/s/emacs % 
>
> Ha!  Thanks for tracking it down.
>
> I installed the patch below into `master` to try and avoid this problem.
>
>
> Stefan
>
>
> diff --git a/lisp/gnus/message.el b/lisp/gnus/message.el
> index f33454e704..e60ea4f0e8 100644
> --- a/lisp/gnus/message.el
> +++ b/lisp/gnus/message.el
> @@ -854,18 +854,24 @@ message-sendmail-f-is-evil
>:type 'boolean)
>  
>  (defcustom message-sendmail-envelope-from
> -  ;; `mail-envelope-from' is unavailable unless sendmail.el is loaded.
> -  (if (boundp 'mail-envelope-from) mail-envelope-from)
> +  'obey-mail-envelope-from
>"Envelope-from when sending mail with sendmail.
>  If this is nil, use `user-mail-address'.  If it is the symbol
>  `header', use the From: header of the message."
> -  :version "23.2"
> +  :version "27.1"
>:type '(choice (string :tag "From name")
>(const :tag "Use From: header from message" header)
> +  (const :tag "Obey `sendmail-envelope-from'"

`sendmail-envelope-from' here should be `mail-envelope-from'.

> + obey-mail-envelope-from)
>(const :tag "Use `user-mail-address'" nil))
>:link '(custom-manual "(message)Mail Variables")
>:group 'message-sending)
>  
> +(defun message--sendmail-envelope-from ()
> +  (if (eq message-sendmail-envelope-from 'obey-mail-envelope-from)
> +  (if (boundp 'mail-envelope-from) mail-envelope-from)
> +message-sendmail-envelope-from))
> +
>  (defcustom message-sendmail-extra-arguments nil
>"Additional arguments to `sendmail-program'."
>;; E.g. '("-a" "account") for msmtp
> @@ -5884,11 +5890,11 @@ message-user-mail-address
>  
>  (defun message-sendmail-envelope-from ()
>"Return the envelope from."
> -  (cond ((eq message-sendmail-envelope-from 'header)
> +  (cond ((eq (message--sendmail-envelope-from) 'header)
>(nth 1 (mail-extract-address-components
>(message-fetch-field "from"
> - ((stringp message-sendmail-envelope-from)
> -  message-sendmail-envelope-from)
> + ((stringp (message--sendmail-envelope-from))
> +  (message--sendmail-envelope-from))
>   (t
>(message-make-address
>  
> diff --git a/lisp/mail/emacsbug.el b/lisp/mail/emacsbug.el
> index 1c2f11680b..fea7619b50 100644
> --- a/lisp/mail/emacsbug.el
> +++ b/lisp/mail/emacsbug.el
> @@ -239,8 +239,8 @@ report-emacs-bug
>;; Stop message-mode stealing the properties we will add.
>(set (make-local-variable 'message-strip-special-text-properties) nil)
>;; Make sure we default to the From: address as envelope when sending
> -  ;; through sendmail.
> -  (when (and (not message-sendmail-envelope-from)
> +  ;; through sendmail.  FIXME: Why?
> +  (when (and (not (message--sendmail-envelope-from))
>(message-bogus-recipient-p (message-make-address)))
>   (set (make-local-variable 'message-sendmail-envelope-from) 'header)))
>  (rfc822-goto-eoh)

dme.
-- 
But are you safe Miss Gradenko?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later

2019-12-03 Thread David Edmondson
On Tuesday, 2019-12-03 at 20:15:02 +01, Gregor Zattler wrote:

>> As best I can determine, this relates to the order in which things are
>> loaded.
>>
>> If you load message.el before setting `mail-specify-envelope-from',
>> things are broken (sorry for the long lines):
>>
>> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require 
>> 'message) (setq mail-specify-envelope-from t mail-envelope-from 'header) 
>> (message \"%s\" message-sendmail-envelope-from))"
>> nil
>> disaster-area ~/s/emacs % 
>>
>> ...but if you load it after, things work fine:
>>
>> disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (setq 
>> mail-specify-envelope-from t mail-envelope-from 'header) (require 'message) 
>> (message \"%s\" message-sendmail-envelope-from))"
>> header
>> disaster-area ~/s/emacs %
>>
>> This doesn't appear to be new behaviour - 26.1 does the same.
>
> this is astonishing, since my test script behaves different with
> emacs build with different last commits!?

There may well be other layers of complication :-)

>> This is related to the way that `message-sendmail-envelope-from' is
>> initialised from `mail-envelope-from', and it's
>> `message-sendmail-envelope-from' that matters, because you end up in
>> `message-send-mail-with-sendmail'.
>
> At the moment I cannot follow...

At least in 27, I don't think that you end up using `sendmail-send-it',
because I don't believe that message.el is looking at
`send-mail-function'.

>> message.el is being loaded by “(require 'notmuch)” in your example,
>> which is happening before `mail-specify-envelope-from' is set, so you
>> see the failure mode described.
>
> ... but in my example the setq forms precede every call to
> message/notmuch (as in your example)!?

That's not the case. Your example is:

> ~/src/emacs/src/emacs -Q -nw -L ~/src/notmuch/emacs/ --eval "(require 
> 'notmuch)" -f notmuch -l /tmp/test.el

This loads (via the require) notmuch.el, and consequently message.el,
*before* it loads /tmp/test.el, so the setq calls happen after
message.el has been loaded.

> [And in my emacs configuration the customizations made with emacs'
> customization interface (among others the three variables which are
> setq in my test script) are loaded before almost anything else,
> especially message/notmuch, see below]
>
>> The example you provided is obviously contrived to show the problem -
>> are you hitting it in normal use?
>
> Absolutely.  I struggle with this at least since 2nd of August and have
> reproduced this behaviour dozens of times.  It took my several
> attempts to isolate the problem.
>
> I use https://github.com/xundeenergie/exim4-multiaccount version
> 1.57 as of 2018-06-05 in order to send emails through different
> smarthosts.
>
> I do this every day and with emacs from sources newer than commit
> 01739625704aaaea6831cef459a4a53171689513 I'm e.g. not able to send
> emails with my work email address ot to this mailing list.  This
> is especially annoying since sending fails silently.  So
> relatively important emails as e.g. announcements of downtimes did
> not reach their intended audience.
>
> The whole thing is above my elisp knowledge.  Is it possible you
> describe something which is not the problem I described?

I think that the above explanation applies to the example that you
provided here. There may well be a different explanation for what
happens with your real configuration.

dme.
-- 
I had my eyes closed in the dark.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [BUG] notmuch-emacs: spoils sendmail -f with emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c and later

2019-12-03 Thread David Edmondson
On Sunday, 2019-12-01 at 18:10:59 +01, Gregor Zattler wrote:

> [@Stefan: FYI]
> Dear notmuch developers,
>
> I use notmuch-emacs configured with
> (setq mail-specify-envelope-from t)
> (setq mail-envelope-from 'header)
> (setq send-mail-function 'sendmail-send-it)
>
> this should/used to invoke sendmail (in my case exim4) with the email
> address given in the From: header of the message buffer as
> argument to sendmails -f option.

Wow, this was, err, “interesting”.

Comments below.

> Since emacs 27 commit 3a59cc84069376802ba8fd731b524d78db58262c
>
>  3a59cc84069376802ba8fd731b524d78db58262c
>  Author: Stefan Monnier 
>  AuthorDate: Tue Jul 30 16:37:01 2019 -0400
>  Commit: Stefan Monnier 
>  CommitDate: Tue Jul 30 16:37:01 2019 -0400
>
>  Parent: add146f09f * lisp/bindings.el 
> (mode-line-defining-kbd-macro): New defvar.
>  Contained:  master
>  Follows:emacs-26.1 (6691)
>
>  * lisp/gnus/message.el: Reduce redundancy with send-mail-function
>
>  (message-send-mail-function) : Remove `local-library` tests
>  for libs distributed with Emacs.
>  (message-use-send-mail-function): New function.
>  (message-default-send-mail-function): Default to it, and remove cases
>  already handled by it.
>  (message--default-send-mail-function): New function.
>  (message-send-mail-function) : Use it as new default.
>  (message-sendmail-f-is-evil): Obey mail-specify-envelope-from if 
> available.
>  (message-check, message-with-reply-buffer): Use `declare`.
>  (message-smtpmail-send-it): smtpmail accepts mail-header-separator,
>  so simplify and declare obsolete.
>  (message-send-mail-with-mailclient): Declare obsolete.
>  (message-check-news-body-syntax): Don't presume that the checksum is
>  a fixnum.
>
>
> this actually invokes sendmail -f with an address derived from the
> EMAIL environment variable.
>
>
> It took me some time to understand, that there is no problem with
> compose-mail/message-send-and-exit which are bound to ^X m and ^C
> ^C respectively within a barely configured emacs which I used for
> testing.
> If instead notmuch is loaded compose-mail/message-send-and-exit
> and notmuch-mua-new-mail/notmuch-mua-send behave different.
>
> With this command (with test.el as attached):
>
> ~/src/emacs/src/emacs -Q -nw -l /tmp/test.el
>
> compose-mail/message-send-and-exit rightly show
> -f exam...@example.org in the file /tmp/result (and then there is
> an error because the notmuch commands are not known).
>
> While this command
>
> ~/src/emacs/src/emacs -Q -nw -L ~/src/notmuch/emacs/ --eval "(require 
> 'notmuch)" -f notmuch -l /tmp/test.el
>
> wrongly show some other value for -f, depending on your EMAIL
> environment variable, for both compose-mail/message-send-and-exit
> and notmuch-mua-new-mail/notmuch-mua-send.
>
>
> I read the code but I have no idea why and how to debug this.
>
> Ciao; Gregor
> --
>  -... --- .-. . -.. ..--.. ...-.-
>
> (find-file "/tmp/sent")
> (insert "empty")
> (kill-region (point-min) (point-max))
> (write-file "/tmp/sent")
> (kill-buffer)
>
> (find-file "/tmp/result")
> (kill-region (point-min) (point-max))
> (write-file "/tmp/result")
> (kill-buffer)
>
> (find-file "/tmp/show-sendmail-args.sh")
> (kill-region (point-min) (point-max))
> (insert "#!/bin/sh
> echo $* >> /tmp/result")
> (write-file "/tmp/show-sendmail-args.sh")
> (chmod "/tmp/show-sendmail-args.sh" 448)
>
> (setq sendmail-program "/tmp/show-sendmail-args.sh")
> (setq mail-specify-envelope-from t)
> (setq mail-envelope-from 'header)
> (setq send-mail-function 'sendmail-send-it)
>
> (compose-mail "Echo Mail Server " "test"
>'((From: . "exam...@example.org")))

This example, and the one below, are broken - you can't use “From:”
here, it has to be “From”. Changing that doesn't fix it, though.

> (message-send-and-exit)
>
> (notmuch-mua-mail "Echo Mail Server " "test"
>'((From: . "exam...@example.org")))
> (notmuch-mua-send-and-exit)
>
> (save-buffers-kill-terminal)

As best I can determine, this relates to the order in which things are
loaded.

If you load message.el before setting `mail-specify-envelope-from',
things are broken (sorry for the long lines):

disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (require 
'message) (setq mail-specify-envelope-from t mail-envelope-from 'header) 
(message \"%s\" message-sendmail-envelope-from))"
nil
disaster-area ~/s/emacs % 

...but if you load it after, things work fine:

disaster-area ~/s/emacs % ./src/emacs -Q -nw -batch --eval "(progn (setq 
mail-specify-envelope-from t mail-envelope-from 'header) (require 'message) 
(message \"%s\" message-sendmail-envelope-from))"
header
disaster-area ~/s/emacs %

This doesn't appear to be new behaviour - 26.1 does the same.

This is related to the way that `message-sendmail-envelope-from' is
initialised from `mail-envelope-from', and it's
`message-sendmail-envelope-from' that matters, b

[PATCH] emacs: A prefix argument kills rather than browsing URLs

2019-12-02 Thread David Edmondson
In `notmuch-show', the "B" key (notmuch-show-browse-urls) will kill
the URL if called with a prefix argument rather than browsing
directly.
---
 emacs/notmuch-show.el | 14 +-
 1 file changed, 9 insertions(+), 5 deletions(-)

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e13ca3d7..ef2bf1e0 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -2540,12 +2540,16 @@ message."
(push (match-string-no-properties 0) urls))
  (reverse urls
 
-(defun notmuch-show-browse-urls ()
-  "Offer to browse any URLs in the current message."
-  (interactive)
-  (let ((urls (notmuch-show--gather-urls)))
+(defun notmuch-show-browse-urls (&optional kill)
+  "Offer to browse any URLs in the current message.
+With a prefix argument, copy the URL to the kill ring rather than
+browsing."
+  (interactive "P")
+  (let ((urls (notmuch-show--gather-urls))
+   (prompt (if kill "Copy URL to kill ring: " "Browse URL: "))
+   (fn (if kill #'kill-new #'browse-url)))
 (if urls
-   (browse-url (completing-read "Browse URL: " (cdr urls) nil nil (car 
urls)))
+   (funcall fn (completing-read prompt (cdr urls) nil nil (car urls)))
   (message "No URLs found."
 
 (provide 'notmuch-show)
-- 
2.23.0

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


Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

2019-12-01 Thread David Edmondson
On Friday, 2019-11-29 at 13:01:00 -07, Sean Whitton wrote:

> On Wed 27 Nov 2019 at 08:52PM +00, David Edmondson wrote:
>> It's a lot to ask, I know, but if you could provide a specific set of
>> messages with a corresponding initial query that fails for you after
>> limiting using your function, it would be helpful.
>
> You should be able to download an mbox of the thread I was using for
> testing here:
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=945195;mbox=yes
>
> The Org-mode link I was using to open the thread is
> [[notmuch:id:20191125214551.31596-1-...@fifthhorseman.net][dkg's v2 for 
> S/MIME decryption]]

This works exactly as I would expect with the patch I previously sent.

I downloaded the messages, added them to my corpus and remove the inbox
and unread tags.

Then, if I execute:

  (notmuch-show “thread:{id:20191125214551.31596-1-...@fifthhorseman.net}”)

and use your function the list of messages open is limited as I
expected.

“As I expected” means that if I pass no prefix, all of the messages that
include patches are open. With a prefix argument of “1”, only the first
set of patches are open. With a prefix argument of “2”, only the v2
patches are open.

Did I misunderstand the behaviour that you expect?

> Please excuse me for not preparing more formal steps to reproduce --
> since I consider the bug to be in ol-notmuch.el and my fix to that file
> prevents this bug from showing up, I am not really willing to invest a
> lot of time in preparing a different sort of fix.

Understood. My interest is in improving notmuch generally.

dme.
-- 
No proper time of day.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2 2/8] emacs/tree: add notmuch-tree-goto-matching-message

2019-11-28 Thread David Edmondson
On Thursday, 2019-11-28 at 08:13:55 -08, William Casarin wrote:

> This function captures some common logic when jumping to matching
> messages in notmuch-tree mode.
>
> We also add a new return value (t or nil), that indicates if there was
> a next matching message in the thread to show.
>
> Signed-off-by: William Casarin 
> ---
>  emacs/notmuch-tree.el | 17 +
>  1 file changed, 13 insertions(+), 4 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index 4bc05160..9f2d87b5 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -577,12 +577,22 @@ message will be \"unarchived\", i.e. the tag changes in
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> +(defun notmuch-tree-goto-matching-message (&optional prev)
> +  "Move to the next or previous matching message.
> +
> +Returns t if there was a next matching message in the thread to show,
> +nil otherwise."
> +  (let (last)
> +(while (and (not (setq last (if prev (bobp) (eobp
> +(not (notmuch-tree-get-match)))
> +  (forward-line (if prev -1 nil)))

A function scope variable to store the direction would save testing
`prev' every time around the loop.

Same question about the local variable as for the last patch.

> +(not last)))
> +
>  (defun notmuch-tree-prev-matching-message ()
>"Move to previous matching message."
>(interactive)
>(forward-line -1)
> -  (while (and (not (bobp)) (not (notmuch-tree-get-match)))
> -(forward-line -1))
> +  (notmuch-tree-goto-matching-message t)
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> @@ -590,8 +600,7 @@ message will be \"unarchived\", i.e. the tag changes in
>"Move to next matching message."
>(interactive)
>(forward-line)
> -  (while (and (not (eobp)) (not (notmuch-tree-get-match)))
> -(forward-line))
> +  (notmuch-tree-goto-matching-message)
>(when (window-live-p notmuch-tree-message-window)
>  (notmuch-tree-show-message-in)))
>  
> -- 
> 2.23.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
Oh by the way, which one's Pink?
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH v2 1/8] emacs/tree: return true if a thread was found in next-thread

2019-11-28 Thread David Edmondson
On Thursday, 2019-11-28 at 08:13:54 -08, William Casarin wrote:

> This will allow us to pop back to parent buffers when there are no
> more threads to jump to.
>
> Signed-off-by: William Casarin 
> ---
>  emacs/notmuch-tree.el | 8 ++--
>  1 file changed, 6 insertions(+), 2 deletions(-)
>
> diff --git a/emacs/notmuch-tree.el b/emacs/notmuch-tree.el
> index c00315e8..4bc05160 100644
> --- a/emacs/notmuch-tree.el
> +++ b/emacs/notmuch-tree.el
> @@ -620,10 +620,14 @@ message will be \"unarchived\", i.e. the tag changes in
>(notmuch-tree-thread-top))
>  
>  (defun notmuch-tree-next-thread ()
> +  "Get the next thread in the current tree. Returns t if a thread was
> +found or nil if not."
>(interactive)
>(forward-line 1)
> -  (while (not (or (notmuch-tree-get-prop :first) (eobp)))
> -(forward-line 1)))
> +  (let (end)
> +(while (not (or (notmuch-tree-get-prop :first) (setq end (eobp
> +  (forward-line 1))
> +(not end)))

Does using the variable add much value here? It makes the code look more
strange and removing it would add the cost of just one more call to
`eobp'.

>  
>  (defun notmuch-tree-thread-mapcar (function)
>"Iterate through all messages in the current thread
> -- 
> 2.23.0
>
> ___
> notmuch mailing list
> notmuch@notmuchmail.org
> https://notmuchmail.org/mailman/listinfo/notmuch

dme.
-- 
But uh oh, I love her because, she moves in her own way.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

2019-11-27 Thread David Edmondson
On Wednesday, 2019-11-27 at 10:42:59 -07, Sean Whitton wrote:

> On Wed 27 Nov 2019 at 01:08PM +00, David Edmondson wrote:
>
>> On Tuesday, 2019-11-26 at 16:25:29 -07, Sean Whitton wrote:
>>
>>> On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote:
>>>
>>>> The poor behaviour is just a side effect of the way that queries are
>>>> composed to implement the filter functionality. Does the attached patch
>>>> help?
>>>
>>> Unfortunately, it is still broken in my test case.
>>
>> Could you describe your test case please? (We could remove emacs-orgmode
>> for that conversation if you think it appropriate.)
>
> I have this function which calls notmuch-show-filter-thread:
>
> (defun spw--notmuch-show-filter-thread-patches (&optional reroll-count)
>   (interactive "P")
>   (let ((subject-filter
>  (if reroll-count
>  (let ((n (prefix-numeric-value reroll-count)))
>(if (= n 1)
>"(subject:/\\[.*PATCH[^v]*\\]/ or 
> subject:/\\[.*PATCH.*v1.*\\]/)"
>  (concat "subject:/\\[.*PATCH.*v" (number-to-string n) 
> ".*\\]/")))
>"subject:/\\[.*PATCH.*\\]/ ")))
> (notmuch-show-filter-thread
>  (concat "tag:unread or tag:flagged or ("
>  subject-filter
>  " and not subject:'Re:' and not subject:'Info received')"
>
> Copy-pasting the whole function since you mentioned you were interested
> in the notmuch patch review functionality I'm working on, but let me
> know if you want a narrower test case.

If this does what I think, which is to filter the current thread to show
only those messages that contain actual patches (with an optional
version number), then, with the previous patch I sent, it seems to work
just fine for me if the original `notmuch-show' query is something like
“thread:a or thread:b”, where those threads both contain both patches
and comments on the patches.

An example call I used initially is:

(notmuch-show "thread:{id:20191117222929.1064-1-j...@jb55.com} or 
thread:{id:20190419035659.28961-1-congdan...@gmail.com}")

Hopefully this is a query that will work for you as well. Limiting this
using your function behaves as I would expect.

It's a lot to ask, I know, but if you could provide a specific set of
messages with a corresponding initial query that fails for you after
limiting using your function, it would be helpful.

>>> The purpose of `notmuch-extract-thread-patches' is to extract a whole
>>> git-send-email(1) patch series at a time, because that is usually what
>>> one wants to do.  There are `notmuch-extract-message-patches' and
>>> `notmuch-show-pipe-message' for single patches.
>>
>> Then I think the approach that you have (wrapping the query in
>> thread:{}) makes perfect sense.
>
> To my mind, it makes sense only to the extent that committing hacky
> workarounds is something which makes sense :)

Well, if we stick to the idea that the first argument to `notmuch-show'
can only be a thread ID, then yes.

Given that thread IDs have some annoying properties, it would be
convenient to allow the caller to pass an arbitrary query.

If we fix anything that is broken by that, I'm happy to provide a patch
that changes the code (and any implicit or explicit documentation)
accordingly.

dme.
-- 
This is the time. This is the record of the time.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

2019-11-27 Thread David Edmondson
On Tuesday, 2019-11-26 at 16:25:29 -07, Sean Whitton wrote:

> On Tue 26 Nov 2019 at 10:52PM +00, David Edmondson wrote:
>
>> The poor behaviour is just a side effect of the way that queries are
>> composed to implement the filter functionality. Does the attached patch
>> help?
>
> Unfortunately, it is still broken in my test case.

Could you describe your test case please? (We could remove emacs-orgmode
for that conversation if you think it appropriate.)

>>> Further, my package 'mailscripts' tries to pass the current value of
>>> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>>>
>>> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>>>
>>> https://manpages.debian.org/notmuch-extract-patch
>>>
>>> If `notmuch-show-thread-id' contains a query which returns a single
>>> message, the wrong value is passed to notmuch-extract-patch(1), such
>>> that it may not extract all of the patches in the thread.
>>
>> It's not clear to me that this is broken.
>>
>> notmuch-extract-patch seems to be properly extracting patches from the
>> messages that match the query.
>>
>> If the current `notmuch-show' buffer query doesn't match the entire
>> thread, why should `notmuch-extract-thread-patches' be expected to apply
>> patches from the whole thread?
>
> The purpose of `notmuch-extract-thread-patches' is to extract a whole
> git-send-email(1) patch series at a time, because that is usually what
> one wants to do.  There are `notmuch-extract-message-patches' and
> `notmuch-show-pipe-message' for single patches.

Then I think the approach that you have (wrapping the query in
thread:{}) makes perfect sense.

> (I note that this is a mailscripts design question, not strictly
> relevant to the issue of ol-notmuch.el causing the
> notmuch-show-thread-id variable to be mispopulated.  Thank you for your
> engagement with mailscripts, regardless!)

Well, I'm interested in the functionality that it provides :-)

Presumably this all arises because thread IDs are neither stable nor
portable, so they are inappropriate to store in an external document (as
an org-mode link in this case)?

dme.
-- 
Hello? Is anybody home? Well, you don't know me, but I know you.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

2019-11-26 Thread David Edmondson
On Tuesday, 2019-11-26 at 14:57:28 -07, Sean Whitton wrote:

> On Tue 26 Nov 2019 at 08:05PM +00, David Edmondson wrote:
>
>> Could you explain how you were using `notmuch-show-thread-id' in a way
>> that was broken by the presence of an arbitrary query?
>
> I've observed that the standard notmuch command
> `notmuch-show-filter-thread' doesn't work in a buffer opened by
> `org-notmuch-follow-link'.

The poor behaviour is just a side effect of the way that queries are
composed to implement the filter functionality. Does the attached patch
help?

> Further, my package 'mailscripts' tries to pass the current value of
> `notmuch-show-thread-id' to notmuch-extract-patch(1).
>
> https://git.spwhitton.name/mailscripts/tree/mailscripts.el#n72
>
> https://manpages.debian.org/notmuch-extract-patch
>
> If `notmuch-show-thread-id' contains a query which returns a single
> message, the wrong value is passed to notmuch-extract-patch(1), such
> that it may not extract all of the patches in the thread.

It's not clear to me that this is broken.

notmuch-extract-patch seems to be properly extracting patches from the
messages that match the query.

If the current `notmuch-show' buffer query doesn't match the entire
thread, why should `notmuch-extract-thread-patches' be expected to apply
patches from the whole thread?

diff --git a/emacs/notmuch-show.el b/emacs/notmuch-show.el
index e13ca3d7..ecbc03d2 100644
--- a/emacs/notmuch-show.el
+++ b/emacs/notmuch-show.el
@@ -1311,7 +1311,7 @@ and THREAD.  The next query is THREAD alone, and serves as a
 fallback if the prior matches no messages."
   (let (queries)
 (push (list thread) queries)
-(if context (push (list thread "and (" context ")") queries))
+(if context (push (list "(" thread ") and (" context ")") queries))
 queries))
 
 (defun notmuch-show--build-buffer (&optional state)

dme.
-- 
I can't explain, you would not understand. This is not how I am.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Bug: ol-notmuch.el: calls `notmuch-show' with arbitrary search query

2019-11-26 Thread David Edmondson
On Thursday, 2019-11-21 at 14:37:44 -07, Sean Whitton wrote:

> The function `org-notmuch-follow-link' in {org,ol}-notmuch.el calls
> `notmuch-show' with an arbitrary notmuch search query.  However, the
> docstring for `notmuch-show' specifies that a notmuch thread ID, rather
> than an arbitrary notmuch query, should be supplied to `notmuch-show'.
>
> The effect of this is that the variable `notmuch-show-thread-id' may
> contain an arbitrary search query rather than a thread ID.  That broke
> some code of mine which uses that variable.

Could you explain how you were using `notmuch-show-thread-id' in a way
that was broken by the presence of an arbitrary query?

(Not arguing right or wrong, just trying to understand the problem.)

> `org-notmuch-follow-link' needs to continue to accept an arbitrary query
> (as notmuch thread IDs are not stable), but it should convert it to a
> thread ID before passing it to `notmuch-show'.

dme.
-- 
I'd rather be with you than flying through space.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH 5/7] emacs/tree: add notmuch-tree-archive-message-than-next-or-exit

2019-11-18 Thread David Edmondson
On Sunday, 2019-11-17 at 15:17:58 -08, William Casarin wrote:

> I'll push out a v2 later if this gets enough Concept ACKs.

The changes make sense to me in principle, but I don't use
notmuch-tree. It would be good if someone who does could try them and
comment.

dme.
-- 
I do believe it's Madame Joy.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: wish: notmuch-emacs: handle RFC822 attachments as email (allow for replying)

2019-11-13 Thread David Edmondson
On Wednesday, 2019-11-13 at 09:42:26 +01, Gregor Zattler wrote:

> Dear notmuch developers,
>
> notmuch-emacs shows rfc822 attachments as emails which is nice,
> but with point in such attachment it is not possible to act on it
> as an email as for instance reply to it.
>
> It would be nice if replying and forwarding such
> email-as-attachment would be possible.
>
>
> As a mailing list owner I get emails from mailman if mails are
> for some reason to be approved before distribution.  They contain
> two rfc822 Attachments: The original email which is to be
> approved and a second email to which I am could reply in order to
> delete or approve said message.  This is an incredibly useful
> interface to mailman since it does not involve a context switch.
> You read the mailinglist and act on emails, that's it.  Sadly
> with notmoch-show this is not possible (as for instance is with
> mutt).

Two approaches to this occur to me:

1. extract the attachment, add it to the database and use normal reply
   processing (maybe remember to remove the message from the database
   after?),
2. hack something just in the emacs UI to generate a reply to the part.

The second is probably quicker to implement, but will side-step a bunch
of normal notmuch processing of the reply (whether this is important or
not I'm unsure).

The first seems “right”, but is perhaps invasive?

dme.
-- 
I'm not living in the real world, no more, no more.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] Add --message-headers flag to notmuch-show

2019-11-13 Thread David Edmondson
On Tuesday, 2019-11-12 at 17:19:13 -05, Daniel Kahn Gillmor wrote:

> Are you sure you want the configuration in the config file and not in
> the database itself?

That's fine with me.

dme.
-- 
So tap at my window, maybe I might let you in.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: [PATCH] emacs: bind C-u Z to notmuch-tree-from-search-thread

2019-11-13 Thread David Edmondson
On Wednesday, 2019-11-13 at 00:00:04 -08, William Casarin wrote:

> This is an unbound function that is quite useful. It opens a selected
> thread in notmuch-tree from the current search query.

Seems fine to me. Not crazy about the binding, but it will suffice.

> Signed-off-by: William Casarin 
> ---
>  emacs/notmuch.el | 9 ++---
>  1 file changed, 6 insertions(+), 3 deletions(-)
>
> diff --git a/emacs/notmuch.el b/emacs/notmuch.el
> index 773d1206..b5c361ca 100644
> --- a/emacs/notmuch.el
> +++ b/emacs/notmuch.el
> @@ -517,10 +517,13 @@ thread."
> (concat "*" (truncate-string-to-width subject 30 nil nil 
> t) "*"))
>(message "End of search results."
>  
> -(defun notmuch-tree-from-search-current-query ()
> +(put 'notmuch-tree-from-search-current-query 'notmuch-prefix-doc
> + "Show the selected thread with notmuch-tree")
> +(defun notmuch-tree-from-search-current-query (&optional search-thread)
>"Call notmuch tree with the current query"
> -  (interactive)
> -  (notmuch-tree notmuch-search-query-string))
> +  (interactive "P")
> +  (if search-thread (notmuch-tree-from-search-thread)
> +(notmuch-tree notmuch-search-query-string)))
>  
>  (defun notmuch-tree-from-search-thread ()
>"Show the selected thread with notmuch-tree"
>
> base-commit: 7ad7cfbff232431377562271901ee00202bf0bd0
> -- 
> 2.23.0

dme.
-- 
But he said, leave me alone, I'm a family man.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-12 Thread David Edmondson
On Tuesday, 2019-11-12 at 05:17:46 -08, William Casarin wrote: 

David Edmondson  writes: 
On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote:  
I'm trying instead to use the tree view, this seems to me the 
more natural way to view threads. So I immediately do `Z' 
whenever I enter a thread. I would like to have the option to 
enter tree view automatically for a thread from the search 
buffer. Is it possible?  


“Z” in search mode should take you directly to tree mode. 


true, but it opens tree mode for the entire search result. I 
find myself doing `c i z Ctrl-v` to open the tree view for a 
specific thread, but perhaps it would make sense if there was a 
default keybind for this. 


Hmm, yes, that's a bit annoying.

I'd suggest 'z' as a good binding, but obviously it's already 
used. What would make sense?


dme.
--
So clap your hands together, make beats with cutlery.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Unread handling

2019-11-11 Thread David Edmondson
On Monday, 2019-11-11 at 00:16:17 +01, Johan Parin wrote: 

I'm probably doing something wrong but I find myself frustrated 
with the handling of unread in the emacs-mua. 

In notmuch-search I found the default bold face for unread of 
notmuch-search-unread-face not enough to make them stand out so 
I tried something like 

  (setq notmuch-search-line-faces 
  '(("unread" . '(:foreground "SkyeBlue")) 


  (setq notmuch-search-line-faces 
  '(("unread" :foreground "SkyeBlue")))


(And I don't have a “SkyeBlue”, just “SkyBlue”.) 

which ought to work according to the doc, but did not 
work. Fortunately however it works to define a new face with 
defface and use that. 

  (setq notmuch-search-line-faces 
'(("unread" . my/notmuch-unread-face))) 

So that problem solved. 

My real frustration lies in the thread view. Typically threads 
will be partially read and I want to read only unread messages. 

I find the show view confusing because I don't clearly see the 
message boundaries. Also I always need to start with C-u M-RET 
to get an overview of the thread. In this view the unread stand 
out a bit due to the colorization of the unread tag, which is 
typically visible. I still would like to be able to colorize the 
entire line or the author here, for unread. Is it possible? 


The single-line summary of the message is drawn using 
notmuch-message-summary-face, which you can customise. This would 
be the same for all messages in the thread, though (no distinction 
for “unread”).


You could perhaps abuse notmuch-tag-formats to force unread 
message header lines to stand out more.


I'm trying instead to use the tree view, this seems to me the 
more natural way to view threads. So I immediately do `Z' 
whenever I enter a thread. I would like to have the option to 
enter tree view automatically for a thread from the search 
buffer. Is it possible? 


“Z” in search mode should take you directly to tree mode.

In tree view however, again I would like to colorize the unread 
messages. Haven't found a way to do this and reading 
notmuch-tree.el it seems it's not possible. Is there a way? 
Since I like to keep my window to 80 chars the tag display is 
outside the visible area and I find myself doing C-e to find the 
unread tags. This is very inconvenient. 

Also I would like to navigate to the next unread message, and 
would prefer the `n' binding to do that instead of go to next 
message. Haven't found a binding for that. 

Finally when entering the tree view I would like the first 
unread message to automatically be shown. 


I'm not a tree mode user, so I'm not familiar with it.

I guess the above can be summarized as, I would like to have the 
option to have a gnus-ish way of viewing threads. 


Tree mode is the closest, I think.

Again, I'm probably doing something wrong and / or am missing 
some possibilities here, it would be very interesting to hear 
others work flow for thread reading. 


notmuch doesn't generally obsess about the “unread” tag quite as 
much as the “inbox” tag. Maybe you are used to orienting yourself 
around “unread” (which is important in Gnus, I'd agree) and 
thinking about how to look at “inbox” instead would help?


dme.
--
I was better off when I was on your side, and I was holding on.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


  1   2   3   4   5   6   7   8   9   10   >