Re: "snoozing" with notmuch?

[David Bremner]

Matt Armstrong  writes:

> My mail yesterday about muting
> (id:qf5vazjjciq@marmstrong-linux.kir.corp.google.com) was in part
> motivated by this question:
>
> Has anybody implemented something like "snooze" in notmuch?
>

There is some related discussion at

  id:4a05c1d8-6da3-44ba-86e3-259191c4d...@me.com

(alas, all the web archives I tried are broken at the moment)

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

Re: notmuch.el: controlling what does and doesn't get expanded in searches

[Jani Nikula]

On Thu, 04 Aug 2016, Carl Worth  wrote:
>>  i) notmuch could have an "also expand tags" feature, where thread based
>> results would auto expand matching tags.  I would set this to
>> "unread".
>
> This approach makes a lot of sense to me based on how notmuch.el works.

My idea on how to do this: I'd like to have a key binding in the show
view to go through a customizable list of rules on how to
collapse/expand the messages. The rules could be:

* [ ] expand all matching messages
  [ ] expand messages having any of the specified tags
  [ ] expand messages having all of the specified tags
* expand all messages
* collapse all messages

(* are mutually exclusive, [ ] are not)

The first rule would define what is displayed by default. So you could
have, for example, "expand all matching messages and any messages that
have both inbox and unread tags", followed by "expand all matching
messages", followed by "expand messages that have inbox tag", followed
by "expand all messages", etc. any way you wish.

It would be a nice bonus if you could specify at which rule to start per
each saved search, instead of the first in the list.

I think this could replace the current M-RET and C-u M-RET
expand/collapse all bindings. Maybe M-RET could be reused for this.

This would obviously not require any changes to the SPC, n, p or other
navigation bindings, which I think are currently just fine.


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

Re: notmuch.el: controlling what does and doesn't get expanded in searches

[Carl Worth]

On Thu, Aug 04 2016, Matt Armstrong wrote:
> Yes, I find the query semantics with respect to tags and threads a bit
> confusing at times.  This is not a problem specific to notmuch, as I
> find the same kinds of issues in GMail.  Usually the problem occurs at
> the semantic border between per-message tags and thread-based
> operations.
>
> I can now explain what I am seeing.

Hi Matt,

I haven't been very active on the notmuch mailing list in quite some
time, but I wanted to poke my head in quickly to welcome you and to
thank you for your contribution.

I really like detailed discussions like this about coming up with good
workflows, and trying to figure out how notmuch could better accommodate
those workflows. I think this is one of the most valuable aspects of
notmuch, (that it lets us ask these kinds of questions).

So, please, keep it up!

>  i) notmuch could have an "also expand tags" feature, where thread based
> results would auto expand matching tags.  I would set this to
> "unread".

This approach makes a lot of sense to me based on how notmuch.el works.

>  ii) notmuch could have an "expand query" feature, where thread based
>  results would use an entirely different query to decide, within a
>  thread, which messages to expand.  I would set this query to
>  "tag:unread".

This approach would necessarily be quite a bit more complex in the
implementation without much difference in the user-visible behavior. So
I don't think we would want to pursue this.

-Carl


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

"snoozing" with notmuch?

[Matt Armstrong]

My mail yesterday about muting
(id:qf5vazjjciq@marmstrong-linux.kir.corp.google.com) was in part
motivated by this question:

Has anybody implemented something like "snooze" in notmuch?

I think of a "snooze" as a temporary mute.

The intent would be to hide messages from the inbox until some future
time, upon which they are automatically promoted back into the inbox.

A more precise spec:

 - if a new message arrives into a "snoozed" thread it too is snoozed
   and is not tagged 'inbox'.

 - (perhaps optinoally) unless it is "to me", which always
   auto-unsnoozes the threads it is part of.

 - when unsnoozed, or when a snooze expires, messages in the thread are
   tagged with inbox.

The difficulty I have is that notmuch doesn't support tags with
timestamps or numerical values.  It might be possible to snooze based on
fixed intervals.  E.g. one unique "snoozed until" tag per day of the
year.  Using this would require some UI facade.


Prior art that I'm aware of:

a) Google Inbox has snooze.  You choose a time and the thread appears in
   your inbox as "new mail", as if it arrived then.  It appears to be
   implemented as a tag on the thread that suppresses message display by
   the client (e.g. if you view your "Google Inbox" mail in Gmail the
   "snoozed" messages appear there as normal).

b) in a past life I filtered low priority mail into hourly and daily
   temporary mailboxes, and had cron entries set up to re-incorporate
   those as incoming mail on an hourly/daily basis.  This was a great
   way to encourage myself to batch-process less important mail.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Flat search and threaded views

[Matt Armstrong]

Yuri D'Elia  writes:

> For example, for a query like "tag:unread AND date:24h..now", I'm shown
> all threads containing unread messages within the last day, which is
> perfect. But when I select a thread (with RET), I'm shown the thread
> from the start.

Yuri, I see you're running into issues similar to what I raised today in
id:qf57fbw4fx4@marmstrong-linux.kir.corp.google.com

So far I think notmuch attemps to give you a useful
https://en.wikipedia.org/wiki/DWIM default behavior with respect to how
it handles threads, but both you and I find it to be surprising or even
undesirable in certain situations.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Flat search and threaded views

[Yuri D'Elia]

On Thu, Aug 04 2016, Jani Nikula  wrote:
>> I'd like to jump directly to the first unread message (and in detail, to
>> the first message that actually matches the query!). It's really not
>> great to have to find what message matched the query, especially for
>> long-running threads.
>
> For me, hitting RET in search does show the first matching message in
> the thread.

Ok, I see now.

The problem is that the search I've built includes both existing
messages and unread ones (with a buffer of a day). So even though I get
a new (unread) message, some existing messages in the thread also match.
When reading a new thread started within the day, all messages match.

So I have a different question:

Can I customize how to jump within a thread? I understand 'unread' is
nothing special and I'd like to keep it that way. So I'd like a quick
way to navigate within a thread to skip to messages matching a certain
tag (ie: unread).

With that, I could setup a hook in notmuch-show to improve the behavior
without making unread special.

> The idea is that the unread tag gets dropped when the cursor visits the
> region of an expanded message, in an approximation of when the user has
> actually read the message. We spent quite a bit of time on this, and at
> least I like this behaviour very much, especially with the red
> overstrike on the unread tag in the buffer.

I've seen this, but it wasn't clear how it was working. I see now the
mechanism, but I need a convenient way to jump to tags in a show buffer.

I have to say, as Matt experienced, I wasn't sure how messages where
expanded until I read that message.

> I suppose we could use a feature to tag matching messages from the
> search view and expanded messages from the show view. You can of course
> do this on the command-line.

You mean 'notmuch tag'? Isn't this what '*' would do?

>> Is there a way to sort the search (either tree/search) by subject or
>> by author? Rarely useful, but it doesn't seem possible.
>
> I don't think so.

I also didn't see a way to do that from the command line.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: notmuch.el: controlling what does and doesn't get expanded in searches

[Matt Armstrong]

Jani Nikula  writes:

> On Thu, 04 Aug 2016, Matt Armstrong  wrote:
>> This question pertains to notmuch built from recent git HEAD, using
>> notmuch.el in show mode (i.e. not tree mode).
>>
>> I sometimes read a thread with a bunch of messages and notmuch.el
>> collapses a bunch of them (even if unread and the search matches tags
>> in every message).  I can't figure out the heuristic notmuch is
>> applying here.
>
> The idea is that all the messages matching the query are expanded, the
> others collapsed. Each expanded message must fully match the query. The
> unread or inbox tags are not special in this regard.
>
> I am not saying this is ideal, but this is how it's supposed to
> work. (Indeed I'd personally like to define e.g. saved search specific
> tags or queries to use for deciding which messages to expand.)

Thank you.

Yes, I find the query semantics with respect to tags and threads a bit
confusing at times.  This is not a problem specific to notmuch, as I
find the same kinds of issues in GMail.  Usually the problem occurs at
the semantic border between per-message tags and thread-based
operations.

I can now explain what I am seeing.  In my notmuch-post-hook I tag
messages according to various categories (mailing lists, etc.).  Every
time I do this I also tag them with 'filtered'.  My
`notmuch-saved-searches` has about 15 sub-queries of the form "tag:inbox
AND tag:".

I also have a saved search to catch the "unfiltered" stuff:

  tag:inbox AND tag:unfiltered

So this occurred:

1) One message was sent to a foo-announce mailing list.  This was not
   caught by my filters, so it was simply tagged 'inbox'.

2) All replies were sent to the main "foo" mailing list, which *was*
   caught by my filters and tagged 'inbox' and 'foo' and 'filtered'.

This is bad for two reasons:

a) If I observed this thread by searching for 'tag:inbox AND tag:foo',
   the initial foo-announce message would not be expanded.  But, as the
   first message in the thread, it is the most important!

b) If I observed this thread by searching for 'tag:inbox AND not
   tag:filtered' (as I do to find all the "uncategorized" stuff in my
   inbox), then the foo-announce mail is expanded but none of the
   others.

This problem isn't specific to my 'filtered' tag approach.  I think it
generalizes to any approach that attempts to split incoming mail.

I've been seeing this problem quite frequently because I'm in an
environment where messages are cc:'d to different mailing lists all the
time.  It is common for threads to be cc'd to new mailing lists
mid-thread, or for people to pull lists off the cc: list mid-thread
(sometimes into private per-person distribution).

In this environment, different messages in those threads area expanded
depending on which query I use to find them.  This is undesirable
because, generally, I want to read every message I have not yet read in
these threads.


>> In particular, pressing SPC does not seem to navigate to the collapsed
>> messages (again, even if they are unread).
>
> SPC and n and p are supposed to navigate expanded messages only. N and P
> navigate all messages (but do not expand by default). Again, the tags
> the messages have do not matter. You can manually expand/collapse
> messages, and that'll affect the navigation.

Note that SPC also archives, and when it does, it archives the entire
thread, not just the expanded messages (i.e. those that match the
current search).  So, this gave rise to the above situation, where I
pressed SPC twice and archived a 40 message thread, with most messages
still unread.


>> Worst case: only the first messages is initially expanded and all
>> subsequent are collapsed.  I press SPC and the cursor goes to the end
>> of search results.  SPC again all the entire thread is archived.
>>
>> This behavior has caused me to accidentally skip messages.  First
>> step for me is understanding what is going on so I can fix it.
>
> Yes, let's first check that notmuch behaves as it is expected, and
> then figure out how to improve it.

I think the semantics make coherent sense for ad-hoc searches.  Things
break down for me when considering an inbox processing workflow heavily
based on archiving.

If I return to a thread after reading the first N messages I need not
see those messages expanded.  I have already read them, so I'd prefer
they be collapsed.  Not much usually does this for me because I archive
aggressively, but I don't always archive.  In these cases I think I'd
prefer expansion instead be based on whether I've read the message
(tag:unread).

Also, I do want threads consisting entirely of read messages to appear
in my inbox searches, so I do not want to simply add "AND tag:unread" to
all of my `notmuch-saved-searches`.

Additionally, if messages that don't match the query are pulled into
threads that don't match the query, and are "unread", I'd like to see
them.  Such messages are quite likely to provide important 

Re: Flat search and threaded views

[Jani Nikula]

On Thu, 04 Aug 2016, Yuri D'Elia  wrote:
> For example, for a query like "tag:unread AND date:24h..now"

BTW the "now" part is redundant, you can use an open ended range
"tag:unread AND date:24h..".

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

Re: Flat search and threaded views

[Jani Nikula]

On Thu, 04 Aug 2016, Yuri D'Elia  wrote:
> Hi everyone, I'm experimenting with notmuch-emacs.el (straight from
> git), and I have a few questions after a few days of testing.
>
> The search buffer packs messages in threads by default. Is there a way
> to have a flat list of strictly matching messages when needed?

Just the command-line interface, AFAIK.

> For example, for a query like "tag:unread AND date:24h..now", I'm shown
> all threads containing unread messages within the last day, which is
> perfect. But when I select a thread (with RET), I'm shown the thread
> from the start.
>
> I'd like to jump directly to the first unread message (and in detail, to
> the first message that actually matches the query!). It's really not
> great to have to find what message matched the query, especially for
> long-running threads.

For me, hitting RET in search does show the first matching message in
the thread.

> Another odd behavior I get as a result is that you obviously need to
> select the unread message explicitly to remove the unread tag.

The idea is that the unread tag gets dropped when the cursor visits the
region of an expanded message, in an approximation of when the user has
actually read the message. We spent quite a bit of time on this, and at
least I like this behaviour very much, especially with the red
overstrike on the unread tag in the buffer.

If you want to remove unread tags without actually reading the messages
(why would you want to do that?), you should probably tag the messages
some other way.

> Applying tags to _individual_ messages is similarly weird, as you
> cannot do that from the search view (they would apply to the entire
> thread). Maybe I'm missing a better way here.

I suppose we could use a feature to tag matching messages from the
search view and expanded messages from the show view. You can of course
do this on the command-line.

> Tree view is only marginally better in both scenarios.
>
> You can start a tree search with 'z', but is there a way to make
> searches from the notmuch-hello box into tree by default?

Click [edit] on the saved searches, customize Search Type for each query
you want to use non-default search for. You can also hit 'Z' in both the
search buffer and the show buffer to display them in the tree view.

In general, '?' will display nice help in almost all notmuch buffers.

> Is there a way to sort the search (either tree/search) by subject or
> by author? Rarely useful, but it doesn't seem possible.

I don't think so.


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

Re: notmuch.el: controlling what does and doesn't get expanded in searches

[Jani Nikula]

On Thu, 04 Aug 2016, Matt Armstrong  wrote:
> This question pertains to notmuch built from recent git HEAD, using
> notmuch.el in show mode (i.e. not tree mode).
>
> I sometimes read a thread with a bunch of messages and notmuch.el
> collapses a bunch of them (even if unread and the search matches tags
> in every message).  I can't figure out the heuristic notmuch is
> applying here.

The idea is that all the messages matching the query are expanded, the
others collapsed. Each expanded message must fully match the query. The
unread or inbox tags are not special in this regard.

I am not saying this is ideal, but this is how it's supposed to
work. (Indeed I'd personally like to define e.g. saved search specific
tags or queries to use for deciding which messages to expand.)

> In particular, pressing SPC does not seem to navigate to the collapsed
> messages (again, even if they are unread).

SPC and n and p are supposed to navigate expanded messages only. N and P
navigate all messages (but do not expand by default). Again, the tags
the messages have do not matter. You can manually expand/collapse
messages, and that'll affect the navigation.

> Worst case: only the first messages is initially expanded and all
> subsequent are collapsed.  I press SPC and the cursor goes to the end of
> search results.  SPC again all the entire thread is archived.
>
> This behavior has caused me to accidentally skip messages.  First step
> for me is understanding what is going on so I can fix it.

Yes, let's first check that notmuch behaves as it is expected, and then
figure out how to improve it.

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

Flat search and threaded views

[Yuri D'Elia]

Hi everyone, I'm experimenting with notmuch-emacs.el (straight from
git), and I have a few questions after a few days of testing.

The search buffer packs messages in threads by default. Is there a way
to have a flat list of strictly matching messages when needed?

For example, for a query like "tag:unread AND date:24h..now", I'm shown
all threads containing unread messages within the last day, which is
perfect. But when I select a thread (with RET), I'm shown the thread
from the start.

I'd like to jump directly to the first unread message (and in detail, to
the first message that actually matches the query!). It's really not
great to have to find what message matched the query, especially for
long-running threads.

Another odd behavior I get as a result is that you obviously need to
select the unread message explicitly to remove the unread tag. Applying
tags to _individual_ messages is similarly weird, as you cannot do that
from the search view (they would apply to the entire thread). Maybe I'm
missing a better way here.

Tree view is only marginally better in both scenarios.

You can start a tree search with 'z', but is there a way to make
searches from the notmuch-hello box into tree by default?

Is there a way to sort the search (either tree/search) by subject or
by author? Rarely useful, but it doesn't seem possible.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

notmuch.el: controlling what does and doesn't get expanded in searches

[Matt Armstrong]

This question pertains to notmuch built from recent git HEAD, using
notmuch.el in show mode (i.e. not tree mode).

I sometimes read a thread with a bunch of messages and notmuch.el
collapses a bunch of them (even if unread and the search matches tags in
every message).  I can't figure out the heuristic notmuch is applying
here.  In particular, pressing SPC does not seem to navigate to the
collapsed messages (again, even if they are unread).

Worst case: only the first messages is initially expanded and all
subsequent are collapsed.  I press SPC and the cursor goes to the end of
search results.  SPC again all the entire thread is archived.

This behavior has caused me to accidentally skip messages.  First step
for me is understanding what is going on so I can fix it.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Linking a privately built -lxapian

[David Bremner]

Matt Armstrong  writes:

> I've got a privately built xapian 4.0 in my $HOME/opt/xapian-core-1.4.0
> dir, and its bin dir in my path.
>
> xapian-config is working like this:
>
> % xapian-config --libs
> -L/usr/local/google/home/marmstrong/opt/xapian-core-1.4.0/lib -lxapian

I don't think the notmuch configure script is very well set up for "one
package per hierarchy". That could probably improved, but a simple
workaround would be to install xapian and notmuch into the same
${foo}/{lib,bin} hierarchy, where foo=${HOME} and foo=/usr/local are
both reasonably well tested, I believe (although not by me).

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