From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: X-Spam-Status: No, score=-4.0 required=3.0 tests=ALL_TRUSTED,BAYES_00 shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from localhost (dcvr.yhbt.net [127.0.0.1]) by dcvr.yhbt.net (Postfix) with ESMTP id 8F9D51F453; Mon, 18 Feb 2019 06:30:44 +0000 (UTC) Date: Mon, 18 Feb 2019 06:30:44 +0000 From: Eric Wong To: Philip Oakley Cc: meta@public-inbox.org Subject: Re: Search summaries by thread? Message-ID: <20190218063044.5muo3jwctdmctmeg@dcvr> References: <7ae8e9d2-babd-3780-36ce-92a86154b4e0@iee.org> <20190217233933.GA12921@dcvr> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: List-Id: Philip Oakley 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 :<)