Search summaries by thread?

Search summaries by thread?

[Philip Oakley]

Hi,

I often use the https://public-inbox.org/git/ search facility.

A recent query https://public-inbox.org/git/?q=precious highlighted that 
it may be useful to have a search summary that also summarises by thread.

In this case it should greatly reduce the number of 'hits' because many 
belong to communal threads, e.g. the "mergetool: what to do about 
deleting precious files?" thread.

Is this something that could be considered?

-- 
Philip

Re: Search summaries by thread?

[Eric Wong]

Philip Oakley <philipoakley@iee.org> wrote:
> Hi,
> 
> I often use the https://public-inbox.org/git/ search facility.
> 
> A recent query https://public-inbox.org/git/?q=precious highlighted that it
> may be useful to have a search summary that also summarises by thread.

So, sorta like combining the subject-only threaded display of
landing page (e.g <https://public-inbox.org/git/>)

Or, perhaps in other words, similar to:
<https://public-inbox.org/git/?q=precious&x=t>
but with only the Subject/Date lines, and no message bodies.

> In this case it should greatly reduce the number of 'hits' because many
> belong to communal threads, e.g. the "mergetool: what to do about deleting
> precious files?" thread.
> 
> Is this something that could be considered?

Definitely.  I don't really like the way the search summary page
as-is, either.

Re: Search summaries by thread?

[Philip Oakley]

Hi Eric,

On 17/02/2019 23:39, Eric Wong wrote:
> Philip Oakley <philipoakley@iee.org> wrote:
>> Hi,
>>
>> I often use the https://public-inbox.org/git/ search facility.
>>
>> A recent query https://public-inbox.org/git/?q=precious highlighted that it
>> may be useful to have a search summary that also summarises by thread.
> So, sorta like combining the subject-only threaded display of
> landing page (e.g <https://public-inbox.org/git/>)
>
> Or, perhaps in other words, similar to:
> <https://public-inbox.org/git/?q=precious&x=t>
> but with only the Subject/Date lines, and no message bodies.

And even better if those messages in the thread that _don't_ have the 
search term at summarised as '.....' to remove multiple irrelevant 
subject lines, e.g. within a big patch series [N/30] where you may have 
only one patch, and it's review, that should be shown)

Even better maybe a limit on the number displayed within any thread 
(e.g. 10), just to reduce the amount of screen display (if it's relevant 
the user will jump to the thread.

Bikeshedding, it might even be a possibility to search just within one 
thread (given a message ID or longer subject line portion to anchor the 
thread)

>
>> In this case it should greatly reduce the number of 'hits' because many
>> belong to communal threads, e.g. the "mergetool: what to do about deleting
>> precious files?" thread.
>>
>> Is this something that could be considered?
> Definitely.  I don't really like the way the search summary page
> as-is, either.

Thanks

Philip

Re: Search summaries by thread?

[Eric Wong]

Philip Oakley <philipoakley@iee.org> wrote:
> And even better if those messages in the thread that _don't_ have the search
> term at summarised as '.....' to remove multiple irrelevant subject lines,
> e.g. within a big patch series [N/30] where you may have only one patch, and
> it's review, that should be shown)

Right, the current search results (even &x=t) won't show
non-matching messages.

> Even better maybe a limit on the number displayed within any thread (e.g.
> 10), just to reduce the amount of screen display (if it's relevant the user
> will jump to the thread.

Not sure if it'll be necessary, or not.  Maybe the relevancies can be
links to individual messages on a single line:

   * common subject here for 4 matches below
     [56%] [42%] [12%] [4%]

> Bikeshedding, it might even be a possibility to search just within one
> thread (given a message ID or longer subject line portion to anchor the
> thread)

Wouldn't that overlap with a browser's native "Find"
functionality in the $MESSAGE_ID/T/ and $MESSAGE_ID/t/ cases?

But it could be a possibility for the $MESSAGE_ID/ (no /[tT])
endpoints, I suppose...

Anyways, I'll try to get to this once the git/cgit integration
stuff is done (soon, I hope; but life stuff interfering :<)