On Tue, Apr 02 2019, Örjan Ekeberg wrote:
> Tomi Ollila writes:
>> two things
>>
>> - I wonder whether we could drop (defun notmuch-message-mark-replied ()...)
>> - why is it needed for backward compatibility ?
>
> Yes, it would be cleaner to simply remove it. My thought was that there
> is a
On Tue, Apr 02 2019, David Bremner wrote:
> Several people have observed that this is surprisingly slow, and we
> have a proposal to add tagging into this code path, so we want to make
> sure it doesn't imply too much of a performance hit.
> ---
> performance-test/T00-new.sh | 30
Hello,
David Bremner writes:
> Is the whole story that you don't like pressing M-p after pressing l
> to bring up the previous query?
Pretty much. I wrote that patch not knowing that notmuch could predict
the next potential search with M-n in the minibuffer (which, as it
stands, does the same
Hi again,
I recently realized that `notmuch-search-tag-all' gives me duplicate
completion candidates in ivy; in particular, it seems to show "-X" once
for every thread (or message?) in the current view that has tag "X". So,
for example, when pressing '*' on a search view with 20 unread threads,
I
Leo Vivier writes:
> Discovering that severely undermined the raison d’être of this patch. I
> tried to do something else with it by having it mimic a similar function
> in mu4e where the point was put at the end of the previous search, but
> I’ve found very little use for it.
>
> I think it’s
Hi all,
I'm wondering which workflow people use for this situation that comes up
frequently for me: I have a search that gives me a bunch of threads, say
new messages from a mailing list, and then I go over them, possibly
reading some threads in detail and skipping over others. Afterwards, I
On Wednesday, 2019-04-03 at 13:24:28 +02, Pierre Neidhardt wrote:
>>> Related: is it possible to search the entire conversation, even when
>>> messages are folded?
>>
>> No.
>>
>>> If not, the workaround would be to temporarily expand-all (once the
>>> above feature is implemented), and search
zaep...@gmail.com writes:
> From 6f73e9aa2031de33eb48a05807295fdb7c3bb566 Mon Sep 17 00:00:00 2001
> From: Leo Vivier
> Date: Wed, 6 Feb 2019 16:44:59 +0100
> Subject: [PATCH 1/4] emacs: Implement notmuch-search-refine
> MIME-Version: 1.0
> Content-Type: text/plain; charset=UTF-8
>
On Wednesday, 2019-04-03 at 11:14:42 +02, Pierre Neidhardt wrote:
> Is it possible to cycle-expand-all subtrees in show-mode, à-la Org?
What do you mean by “subtrees”?
M-RET should open all of the messages in the thread, but it doesn't do
anything about regions that are hidden within messages
On Wednesday, 2019-04-03 at 11:12:27 +02, Pierre Neidhardt wrote:
> Anyone interested? Should I send a patch?
I couldn't figure out when I'd want to use this, as yanking text from
the existing notmuch-show buffer seems straightforward.
Maybe something akin to gnus-dired-mode would be
Hi,
Some pictures embed "exif" metadata with autorotate information.
I know that mu4e can autorotate inlined pictures.
I guess it wouldn't be too hard to implement this for Emacs Notmuch
either.
Anyone?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
Should I send a patch?
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch
Hi,
We have notmuch-search-toggle-order but surprisingly there is no
notmuch-tree-toggle-order.
Besides, I find the default tree order somewhat counter-intuitive: the
threads are sorted newest at the top, but the messages within the thread
are sorted oldest at the top (which quite expected from
That'd be great!
Would you like to implement this?
Either way, the patch looks good to me and it'd be great to see it
merged upstream.
Thanks!
--
Pierre Neidhardt
https://ambrevar.xyz/
signature.asc
Description: PGP signature
___
notmuch mailing
14 matches
Mail list logo
