Re: [PATCH] emacs: bind M-RET to notmuch-tree-from-search-thread

2019-11-13 Thread Teemu Likonen
William Casarin [2019-11-13T14:57:52-08] wrote:

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

Liked-and-Already-Used-by: Teemu Likonen 

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
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 Daniel Kahn Gillmor
On Wed 2019-11-13 01:30:50 +0200, Tomi Ollila wrote:
> On Tue, Nov 12 2019, Daniel Kahn Gillmor wrote:
>
>> And, I still haven't heard any clear arguments for choosing between
>> configurability as an absolute thing or a differential thing.  They have
>> significantly different impact on adopters over time, as the default
>> configuration changes.
>
> I don't understand your question,

configurability as an absolute thing:

 --message-headers=foo,bar,baz

configurability as a differential thing:

  --add-message-header=foo --suppress-message-header=qux

> but I think that configuration option
> for choosing what message headers to return is far worst of the options,
> mostly because configuration and what frontend may desire goes easily
> out if sync (and when managed manually that is what inevitably will
> happen). 

totally agreed, but this is very different from what you said next:

> The option (b) is kinda my favorite, code could be pretty simple, ordering
> (sprinted in order listed), duplicates (rescan request list so far and drop
> if header found) might be the harders questions (and seemed not ;/). 
>
> If option (b) were taken, status quo -- no change in returned headers
> should be maintained -- separate patch series w/ devel/schemata and test
> changes can be sent is there desire for changing that.

afaict, option (b) seems to contemplate configurability, which you say
above you don't want.  Maybe we need a clearer list of options, because
this is getting confusing :P

  --dkg


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


[PATCH] emacs: bind M-RET to notmuch-tree-from-search-thread

2019-11-13 Thread William Casarin
This is an unbound function that is quite useful. It opens a selected
thread in notmuch-tree from the current search query.

Signed-off-by: William Casarin 

---

This is a simpler alternative to id:20191113080004.32214-1-j...@jb55.com

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

diff --git a/emacs/notmuch.el b/emacs/notmuch.el
index 773d1206..0d68d123 100644
--- a/emacs/notmuch.el
+++ b/emacs/notmuch.el
@@ -188,6 +188,7 @@ there will be called at other points of notmuch execution."
 (define-key map "-" 'notmuch-search-remove-tag)
 (define-key map "+" 'notmuch-search-add-tag)
 (define-key map (kbd "RET") 'notmuch-search-show-thread)
+(define-key map (kbd "M-RET") 'notmuch-tree-from-search-thread)
 (define-key map "Z" 'notmuch-tree-from-search-current-query)
 map)
   "Keymap for \"notmuch search\" buffers.")

base-commit: 7ad7cfbff232431377562271901ee00202bf0bd0
-- 
2.23.0

___
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 William Casarin
Teemu Likonen  writes:

> William Casarin [2019-11-13T00:00:04-08] wrote:
>
>> This is an unbound function that is quite useful. It opens a selected
>> thread in notmuch-tree from the current search query.
>
> I agree that it is good idea to bind notmuch-tree-from-search-thread
> command and thus make it show in "C-h m" *Help* buffer. I prefer M-RET
> because
>   - it is quick to type
>   - it feels like variant of RET (notmuch-search-show-thread).

I never thought of that but it I like it.
___
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 Teemu Likonen
William Casarin [2019-11-13T00:00:04-08] wrote:

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

I agree that it is good idea to bind notmuch-tree-from-search-thread
command and thus make it show in "C-h m" *Help* buffer. I prefer M-RET
because
  - it is quick to type
  - it feels like variant of RET (notmuch-search-show-thread).

-- 
///  OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450
//  https://keys.openpgp.org/search?q=tliko...@iki.fi
/  https://keybase.io/tlikonen  https://github.com/tlikonen


signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch


Re: Notmuch, Emacs and pinentry -- oh my

2019-11-13 Thread Ralph Seichter
* Daniel Kahn Gillmor:

> This hypothetical subcommand would just protect the index. [...] you
> will be able to read your mail without access to your long-term secret
> key material [...]

That sounds useful, as does the idea of (un)locking the index. As you
may have seen on the GnuPG mailing list, I have not yet cracked the nut
of pass phrase input in Emacs.

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


Re: unifying and automating draft ("postpone/resume") behavior [was: Re: notmuch "lost" email during power failure]

2019-11-13 Thread Antoine Beaupré
On 2019-11-12 18:03:58, Daniel Kahn Gillmor wrote:
> Hi Antoine--
>
> [epic story and funny rnat trimmed down to the salient bug reports and
>  feature requests because i'm a boring person]

Hi!

[I don't remember what RNAT (reverse network address translation) have to
do with anything, but it's true it was a rather long RANT so maybe I
forgot that I went through some weird addressing along the way. ;)]

> On Tue 2019-11-12 17:19:05 -0500, Antoine Beaupré wrote:
>> I would argue that notmuch should at least allow me to recover from a
>> power failure like this, as a MUA. It should "know" that message-mode
>> stores those messages there, and, why not, also store its tempfiles
>> there.
>
> This seems like a very specific ask.  I think what we want more
> generally is a sensible unification of the notmuch-emacs drafting
> behaviors such that message-mode autosaves are discoverable and
> recoverable in the same way that deliberately-saved drafts are.

Yeah. That is pretty much what I meant to say, but said in a more
useful, constructive and clever way. :p

> If that means that notmuch learns about message-mode drafts, that's one
> solution.  But it could also mean that notmuch-emacs overrides
> message-mode's autosave drafting approach, and fixes things there too.

I think the main problem right now is that "control-x control-s" does
something special in notmuch, in that it adds a message-id to the saved
message even if the message isn't saved yet.

But then when *message-mode* auto-saves those files, the message-id is
not present (just checked). For example this very message has 
References (hidden), From, To, Cc, Subject, In-Reply-To and Fcc headers
on disk, along with the fancy `--text follows this line--` magic blob on
disk, in ~/Mail/drafts/#...

While if I save this message to disk, it looks like a proper email
message. It has a (properly encoded) From header, To, Cc, Subject,
In-Reply-To, Fcc (so far pretty close to message-mode), but then also a
Message-ID, Date, X-Notmuch-Emacs-Draft, MIME-Version, Content-type and
Content-transfer-encoding. And of course, the content *is*
quoted-printable-encoded, which might be a problem for message-mode.

In my opinion, that's the fundamental conflict between the two modes:
message-mode expects buffers (and auto-saved files) to have this weird
exotic format to operate, but it's pretty much exactly the same on-disk
format, while notmuch expects a standard email message, which *differs*
from the actual buffer content. It will be fundamentally difficult to
reconcile those two.

> or, we somehow fix message-mode?

That could be a huge challenge. We'd need to teach it to parse real
RFC852 messages properly, without the magic separator, and to include
proper message IDs and other headers.

Alternatively, maybe message-mode could do the same translation magic
that notmuch does when it saves and loads those files, on write. By
moving the notmuch logic upwards in the stack, everyone could benefit.

But it's kind of a big change.

>> And indeed, if I hit [control-x control-s] on this message, it *does*
>> get saved as a "draft" in that it gets written in:
>>
>> ~/Maildir/drafts/cur/1573596264.M156307P32312.curie:2,DF
>>
>> That's a great improvement already. I don't remember exactly when or how
>> this happened, but that's great and I thank whoever did that for us
>> here.
>
> That was Mark Walters (in Cc), see the series from 2016 starting at:
>
>  id:1479046130-2716-1-git-send-email-markwalters1...@gmail.com
>
> Thank you, Mark!

Yeeeaay! thank you Mark!

>> To make a long story short, I think the following should happen:
>>
>>  1. message-mode should automatically cleanup after itself a little
>> better (not notmuch's job? yay double-negative, that means it's much
>> job!)
>>
>>  2. encrypted emails should *never* be written in cleartext on the
>> filesystem (not notmuch job, which also means it's much job!)
>>
>>  3. notmuch's draft subsystem should know about Emacs' autosave files
>> and somehow show them in the UI
>
> Much of the above sounds like message-mode cleanup work to me.  It might
> be worth asking the message-mode folks to weigh on in this strategy.

For what it's worth, I reviewed the original patchset that was merged
from Mark, and notmuch *does* the right thing with encrypted messages
(issue 2 above): it asks users (configurable) what to do. This, again,
could be moved up into message-mode as well...

> Alternately, it might help to characterize the differences between
> message-mode autosaving and notmuch explicit drafting.
>
>  - message-mode autosaves happen without your knowledge.
>notmuch draft saving only happens when you explicitly C-x C-s
>  
>  - message-mode autosaves are automatically cleaned up from the
>filesystem after you send.  notmuch saved drafts persist in your
>mailstore until you remove them (though they are tagged with
>"delete")

Those two are equivalent for me in notmuch, as "deleted" emails get

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] emacs: bind C-u Z to notmuch-tree-from-search-thread

2019-11-13 Thread William Casarin
David Edmondson  writes:

> 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.

yeah I use this more than Z, so I would like a single-char binding. I
wasn't sure and was hoping someone else had a better idea.

Cheers,
Will
___
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 ( 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


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

2019-11-13 Thread Gregor Zattler
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).

Thanks for your attention, Gregor
--
 -... --- .-. . -.. ..--.. ...-.-

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