From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Chris Siebenmann Newsgroups: gmane.emacs.bugs Subject: bug#67359: 29.1; 29.1: MH-E limited display malfunctions if nothing is matched Date: Wed, 22 Nov 2023 11:21:29 -0500 Message-ID: <3289159.1700670089@apps0.cs.toronto.edu> References: <9058.1700669328@alto> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="35386"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Chris Siebenmann , Eli Zaretskii , Bill Wohler , 67359@debbugs.gnu.org To: Mike Kupfer Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed Nov 22 17:33:20 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1r5qAC-0008zL-Fe for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 22 Nov 2023 17:33:20 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1r5q9v-0006bd-GD; Wed, 22 Nov 2023 11:33:03 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1r5q9r-0006ZC-GD for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:32:59 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1r5q9r-00065S-7b for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:32:59 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1r5q9u-0007wa-Gi for bug-gnu-emacs@gnu.org; Wed, 22 Nov 2023 11:33:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Chris Siebenmann Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 22 Nov 2023 16:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67359 X-GNU-PR-Package: emacs Original-Received: via spool by 67359-submit@debbugs.gnu.org id=B67359.170067077430511 (code B ref 67359); Wed, 22 Nov 2023 16:33:02 +0000 Original-Received: (at 67359) by debbugs.gnu.org; 22 Nov 2023 16:32:54 +0000 Original-Received: from localhost ([127.0.0.1]:59796 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5q9l-0007w3-6m for submit@debbugs.gnu.org; Wed, 22 Nov 2023 11:32:53 -0500 Original-Received: from cliff.cs.toronto.edu ([128.100.3.120]:43439) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1r5pyu-0007by-BL for 67359@debbugs.gnu.org; Wed, 22 Nov 2023 11:21:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=cs.toronto.edu; s=cs202005; h=Message-ID:Date:Content-ID:Content-Type: MIME-Version:References:In-reply-to:Subject:cc:To:From:Sender:Reply-To: Content-Transfer-Encoding:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID; bh=HLCxNgvDBsweAiGcK4GFVC/zuakQrta+djULfQInqKw=; b=rXj/bR5hHSvNw5MOHK7gmqQbBJ 6nrR1csmwGheomjSZID5SE07a9gzgKqBrwZq27SWcQX4I16bB6a4nT7nSLpHjT5NBj9ZAegcUl71r xMQ0vfkF7nVGouX4H8PwShZnZayJGzx8JZqlJMnTXZf7MP6zo9/drf/r4Rzs52OsaCYgXduwO6ndW k9FqGdm1tmd/ME7izFuFq/XBz7DhW8dGiI7yBi/bbECIp+8RP8Jn/x9LrODg6CbdUqCIhfU06WGIE cmJGPAl1kjjrqbE5ruDAnshiyRXI9nrYeP/2idu+A6ssE9c2jHA/p6V2hRZbSPUof5lC1EUGapiVc VTDsznEw==; Original-Received: from apps0.cs.toronto.edu ([128.100.3.40] ident=postfix) by cliff.cs.toronto.edu with esmtp (Exim 4.95) (envelope-from ) id 1r5q0L-00Ab1K-K1; Wed, 22 Nov 2023 11:21:30 -0500 Original-Received: by apps0.cs.toronto.edu (Postfix, from userid 915) id A4EF760352; Wed, 22 Nov 2023 11:21:29 -0500 (EST) Original-Received: from apps0.cs.toronto.edu (localhost [127.0.0.1]) by apps0.cs.toronto.edu (Postfix) with ESMTP id A24E860282; Wed, 22 Nov 2023 11:21:29 -0500 (EST) In-reply-to: <9058.1700669328@alto> Comments: In-reply-to Mike Kupfer message dated "Wed, 22 Nov 2023 08:08:48 -0800." Content-ID: <3289158.1700670089.1@apps0.cs.toronto.edu> X-Mailman-Approved-At: Wed, 22 Nov 2023 11:32:51 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:274770 Archived-At: > > > From: Chris Siebenmann > > > Date: Tue, 21 Nov 2023 19:28:45 -0500 > [...] > > > When you do this, MH-E will first show an error message in a buffer > > > below the folder window and then narrow the main folder window to a > > > single line showing 'scan: no messages match specification'. ('/ w' will > > > then fix the situation.) > > Yes, I can reproduce this. > > Chris, I'm not sure what you're expecting instead. I'm guessing you'd > like to have the original message list in the folder buffer (no need to > type "/ w"), with the error text displayed like a normal error, rather > than in the folder buffer. Do I understand correctly? I think the folder should keep the original message list. I don't know what should be done with the error message, since it's semi-redundant. I say this because the current limit-to code appears to contain an attempt to handle the case where no messages match. mh-narrow-to-header-field has, at the end: (if (null msg-list) (message "No matches") [... regular narrowing code ...] ) but since its parsing of pick output puts 0's in msg-list instead of leaving it empty here, you never get the 'No matches' message. So I think the earlier code should arrange to leave msg-list empty by not adding '0' message numbers to it (they're invalid anyway), and then this code can act normally and people get the 'No matches' message and have nothing happen. On the one hand, showing pick's error message for this is redundant with the 'No matches' message. On the other hand, there might be other pick errors in odder cases that one wouldn't want to throw away. (I ran into this issue because I wrote some general pick-based limit-to-search functions for my own use, and sometimes what I was checking for wasn't there; in that case I definitely want to leave the message list intact. Many people probably use the / stuff without a prefix argument to modify the search terms, or only search for things that are there in at least one message.) - cks