Re: [PATCH v3 0/4] Retrieve GPG keys asynchronously.

2019-09-03 Thread David Bremner
David Edmondson  writes:

> Retrieve GPG keys asynchronously.
>
> v2:
> - Update the label on buttons when they are used to request
>   asyncronous key retrieval.
> - Always update the buffer when key retrieval completes, even if the
>   retrieval failed, so that the label is properly re-generated.
>
> v3:
> - Code review comments from bremner:
>   - Fix spelling.
>   - Fix button label.
>   - Update docstring to describe the redisplay conditions.
>

I went back to this series to try and do the last minor things my self,
but unfortunately I got lost in trying to do the rebase. I think it
collides with a couple of dkg's fixes (9300defd6 and 3c752b855f).  If
either of you has (or can make) a version of this series that applies
cleanly to master, I'd like to get it merged (perhaps with one or two
minor tweaks that I could take care of).

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


Re: v4 of legacy-display cleanup

2019-09-03 Thread David Bremner
Daniel Kahn Gillmor  writes:

> This is the fourth revision of the series that cleans up legacy-display
> protected headers parts so that notmuch users only have to look at one
> subject line.
>
> version 3 can be found at id:20190625014107.12452-1-...@fifthhorseman.net
> version 2 can be found at id:20190531075907.17035-1-...@fifthhorseman.net
> version 1 can be found at id:20190531042825.27774-1-...@fifthhorseman.net
>
> --
> Now that notmuch can handle and interpret protected subject lines, it
> should also avoid forcing the user to look at "legacy display" parts
> that some MUAs (notably enigmail) copies of the protected headers that
> are intended to be rendered only by legacy clients -- clients capable
> of decryption but which don't understand how to handle protected
> headers.
> --

series pushed to master

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


Re: Threading of forwarded messages

2019-09-03 Thread David Bremner
Örjan Ekeberg  writes:

> Hi,
>
> Let me first say that I am a very happy user of notmuch+emacs.  Once the
> initial setup and configuration was done, usage has been a very pleasant
> experience.  It daily saves me from getting lost in the constant torrent
> of incoming e-mail, where most need replies or to be forwarded to others
> to deal with.
>
> One thing that I have not been able to configure is the handling of
> forwarded messages.  Forwarded messages are archived as new messages,
> not linked to the messages being forwarded.  This makes it hard to keep
> track of which messages I have forwarded (and therefore is in the hands
> of someone else).  I would like the messages to be linked into the same
> thread.

This feature should be available in notmuch 0.29.

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


Re: Add limit and offset to notmuch show

2019-09-03 Thread David Bremner
jo...@joergvolbers.de (Jörg Volbers) writes:

> Hi,
>
> I'd like to repeat my wish to add some kind of search limit to 
> notmuch show, like it is already implemented in notmuch search. 

Your previous wish has been noted

 https://nmbug.notmuchmail.org/status/#Wish-list

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


Add limit and offset to notmuch show

2019-09-03 Thread Jörg Volbers

Hi,

I'd like to repeat my wish to add some kind of search limit to 
notmuch show, like it is already implemented in notmuch search. 
Reason being that I written have my own little elisp client which 
allows me to browse through "tagsets", that is, I look at all 
mails corresponding to some predefined sets of tags. On the left 
the tagset, on the right a preview of the matching threads. Since 
it is only a preview, it simply makes no sense to execute all of 
the query, so it would be great if I could simply pass some limits 
to the query.


I believe my use case is not rare. A combination like the 
parameters offset/limit already used by notmuch-search would allow 
to considerably speed up all kind of client operations. The client 
could just act on smaller parts or impose sensible limits. For 
example, if looking at all mails, it makes sense to only show the 
first 500 or so and only load further mails on request.


Regards,
Jörg

--
http://www.joergvolbers.de
https://fu-berlin.academia.edu/jvolbers


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