Re: Flat search and threaded views

[Yuri D'Elia]

On Thu, Aug 04 2016, Yuri D'Elia <wav...@thregr.org> wrote:
> 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.

I've tried to change my workflow to fit notmuch's, for example by
narrowing my default searches only to only match unread messages.

I'm feeling a bit mixed about the interface. This is not my first
approach to tag-based email management (I actually still use mu4e). I
wanted to give notmuch a try, mostly due to the way tags can be
processed easily with afew.

I like how the tagging workflow works, actually. I customized afew and
the way default tags are assigned/managed. Batch-processing with afew is
a breeze. I wrote my own plugin to implement MailMove the way I wanted
in a few hours and overridden a few others. I'm quite happy about this.

I just find the emacs interface a bit confusing.

- Showing search results in threads, even after narrowing queries, is
  not optimal. I'm shown a list of threads which contain tag:unread
  messages, *but* the count is the number of messages in the thread
  itself. I've been tripped multiple times by this.

  I still think a flat search result would be better. I would like to
  jump into the show buffer as it's being done currently (with the whole
  thread) for additional context, but not for the direct search results.

- Tagging individual messages is just cumbersome because of this. I
  often flag individual ids that contain things that I need to act on
  later. I cannot do this straight from the search results. I need to
  read the thread and move the cursor to the appropriate message.

- Even after reconsidering, I find that '*' will  never do what I expect.
  I'd like to tag matching ids (that is, what I'm seeing), not threads.
  
  People often hijack old threads just to find your address. I'm being
  shown huge threads, but in reality I'm just getting a new message and
  I don't really want to manage threads as well as messages. When
  tagging, I almost always tag individual messages. When I tag threads,
  generally is to 'kill' them using afew's KillThreadsFilter.

- The unread mechanism itself is nice, but it doesn't work as you might
  expect if you match also read messages. Easier navigation between tags
  (such as "jump to the next unread message") is something I'm looking
  for.

- I patched notmuch to sync the TRASHED flag. Yes, deleting is a thing
  if you use multiple clients. Would you consider accepting a patch for
  this?

- gnus-alias actually works better than mu4e's "current focus" (which
  it's current identity mechanism). mu4e is a bit more comprehensive on
  that front, but gnus-alias is smoother, which I didn't expect.

I didn't still look at the notmuch-search sources. Do you think it would
be hard to support showing individual ids only? Looks like it's easy to
do from the cli, but might require too many conditions in the source.

mu4e on the other hand offers a guile interface that can be used for
filtering, so I'm not sure which is easier to do :P (implementing afew
with guile, or tweaking notmuch search results).
___
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

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

Query operators

[Yuri D'Elia]

Hi everyone,

I'm a bit baffled by the query syntax. Reading the manual:

``Each term in the query will be implicitly connected by a logical AND
if no explicit operator is provided (except that terms with a common
prefix will be implicitly combined with OR).''

I would have assumed that:

term1 (tag:term2 tag:term3)

would be equivalent to:

term1 AND (tag:term2 AND tag:term3)

but if I read carefully (and by looking at the query results), since
tag: is a common prefix between term2 and term3, it is actually:

term1 AND (tag:term2 OR tag:term3)

am I right? Is this a feature of the xapian query syntax? (can it be
tweaked to _unconditionally_ AND all terms?)

For me, the idea that two terms can be ORed if the prefix is the same
can cause queries to return unexpected results.

What about:

term1 xterm2 xterm3 term2

Is this:

  term1 AND (xterm2 OR xterm3) AND term2

or is it:

  term1 OR xterm2 OR xterm3 OR term2

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

Re: Query operators

[Yuri D'Elia]

On Mon, Aug 29 2016, David Bremner <da...@tethera.net> wrote:
> Yuri D'Elia <wav...@thregr.org> writes:
>
>> term1 AND (tag:term2 OR tag:term3)
>>
>> am I right? Is this a feature of the xapian query syntax? (can it be
>> tweaked to _unconditionally_ AND all terms?)
>
> This is most likely a feature of the "grouping" parameter in
> QueryParser::add_boolean_prefix. It _might_ be the case that passing an
> empty string (in lib/database.cc) will improve this behaviour from your
> point of view.

What's your POV on this? Is it expected/useful in some scenario?

I'd expect all terms to follow the same rules for consistency.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch

Re: Query operators

[Yuri D'Elia]

On Mon, Aug 29 2016, Charlie Allom  wrote:
> You can debug what the real query is by adding NOTMUCH_DEBUG_QUERY=1 to
> your search:
>
>   12:29 YELP-CHARLIE~[local@2.7.12] % NOTMUCH_DEBUG_QUERY=1 notmuch search 
> 'term1 (tag:term2 tag:term3)'
>   Query string is:
>   term1 (tag:term2 tag:term3)
>   Exclude query is:
>   Xapian::Query((Kdeleted OR Kspam OR Kmuted OR Kkilled OR Kjunk))
>   Final query is:
>   Xapian::Query(((Tmail AND Zterm1:(pos=1) AND 0 * (Kterm2 OR Kterm3)) 
> AND_NOT (Kdeleted OR Kspam OR Kmuted OR Kkilled OR Kjunk)))
>   12:29 YELP-CHARLIE~[local@2.7.12] %

That was helpful, but confirms that tag terms are combined with OR:

Query string is:
tag:a -(b c)
Final query is:
=> (0 * Ka AND_NOT (Zb:(pos=1) AND Zc:(pos=2)))

(removed the exclusion for brevity)

Query string is:
tag:a -(tag:b tag:c)
Final query is:
=> (0 * Ka AND_NOT 0 * (Kb OR Kc))

is this because they're both prefixed with tag?
Indeed 'tag:a is:b' combines them with AND.

'tag:a is:b tag:c' is actually (tag:a OR tag:c) AND tag:b.

Why this should be helpful?
It's totally unexpected for me.
___
notmuch mailing list
notmuch@notmuchmail.org
https://notmuchmail.org/mailman/listinfo/notmuch