Feature: search-aware navigation in thread views

[xunam]

Hello,

When opening a thread by pressing Enter from an index view, the search from which the thread was reached seems to be forgotten. Apparently, focus always goes to the first unread message, or to the latest message if there is no unread message. It would be useful to have navigation and visibility options in thread views that take into account matching messages in a thread. Specifically, what I am thinking of is:

• next, previous, first, last matching message
• show, hide non-matching messages
• put focus on the first matching message by default when opening a thread (apparently that is what I usually expect, but expectations may vary between users; that might be optional?)

This would be particularly useful when searching with complex expressions. Think of a situation where you search for a specific message in a long thread that contains the information you are after. Then bower gives you the thread in its entirety with only basic string search with /, ? and n.

[wangp]

Interesting idea. It's not something I would use very often so I don't think I want to add too many keys and options to support it. Perhaps we can introduce a mode in the thread view, toggled at run time, to show only matched messages (probably as a flat list). Then you can use the normal navigation and search facilities within the subset of messages. We might also need a key sequence in the index view to open the thread view directly in that new mode.

For long threads, it would be sometimes be useful to subset the thread in other ways. Hmm.

[wangp]

I experimented with this on the thread-view-only-matched branch. Press Alt-Enter in the index view, or M in the thread view to toggle the mode. Not everything works properly.

[xunam]

Thanks for the experiment ! I have been using this branch for a few days and the feature is already useful.

When opening a thread with Alt-Enter, the focus behaviour is a bit inconsistent. Apparently, when the latest message in the thread does match the search, it is focused, highlighted in the message list and displayed. Otherwise, the first matching message is focused and displayed but not highlighted in the message list.

When the thread view is filtered, only matching messages are displayed but visual space is allocated for the whole thread. This is a bit surprising at first, but I actually found this interesting because it highlights which parts of a large thread are relevant, also it makes the display stable when toggling between filtered and unfiltered. An improvement could be to display the non-matching messages in a different color to provide some visual feedback.

[wangp]

The non-matching messages should be displayed in dark grey (bold black) in the top part; not configurable yet. Perhaps you can't see them because of your terminal theme.

(This is mostly a reminder to self.) I found an issue with this sequence of actions:

1. search for tag:foo in the index view
2. remove foo on one of the resulting threads
3. open the thread -- no messages will be shown

[xunam]

Indeed, I did not see the message lines in my usual terminal (st with a solarized dark theme) but it does display correctly in other terminals (gnome-terminal for instance). I am not sure yet whether this is a bug in st or not…

Besides I don't think bold black is a good choice, because the fact that bold is displayed lighter in some terminals does not feel like something that should be relied upon, and black as color for something discreet does not make sense on light backgrounds. When this becomes configurable, I can choose whatever color I want anyway. As a side note, giving access to other terminal attributes (bold, faint, italic, underline etc) in the color settings would be a nice addition.

Regarding the “note to self”, I can confirm I observe this behaviour too !

[seifferth]

A search-aware thread pager sounds really exciting. Maybe one could even take this idea one step further and have a search-aware message pager without thread awareness. This would be especially useful when going through broken threads that fail to use In-Reply-To and References correctly. In my experience, such threads are easy to track down using a notmuch query (just add some froms and tos and a date range). They are currently kind of hard to navigate in bower, however, since there is currently no way of displaying all matching messages in a flat ordering based on their date only.

[wangp]

Until there's a solution to the issue I mentioned, that idea won't go any further.

A new view for messages without thread awareness could be useful. I think it requires some refactoring though. You may have noticed the index and thread views have a lot of similar but not quite duplicated code. I deliberately wrote the initial versions of bower as quickly as possible, without too much thought about architecture, because I knew that if I couldn't use it as my main MUA within a couple of weeks, I would lose interest and the project would go nowhere. (Bower is actually my second attempt...) But I wouldn't want a third view with more similar-but-different code.

[xunam]

Hello,

Do you have any plan to merge the thread-view-only-matched branch into master ? I am currently stuck with this version because the feature is really useful, but then all updates to the master branch are missing...

[wangp]

I've rebased the branch onto master.

[wangp]

I've pushed a new WIP branch obscure-unmatched-messages that makes unmatched messages visible but sort of hidden (in a darker colour, configurable) and ignored by navigation keys. As before, use Alt-Enter to open the thread, or M to toggle the new mode.

Edit: I've cleaned up the code and switched to using the thread_summary.query field that notmuch provides. This means the set of unmatched messages remains fixed after the search is performed in the index view, and solves the problem described at #77 (comment)

[wangp]

Merged to master.