GNU bug report logs - #67359
29.1; 29.1: MH-E limited display malfunctions if nothing is matched

Previous Next

Full log

Message #14 received at 67359 <at> debbugs.gnu.org (full text, mbox):

From: Chris Siebenmann <cks.emacsbugs-01 <at> cs.toronto.edu>
To: Mike Kupfer <kupfer <at> rawbw.com>
Cc: Chris Siebenmann <cks.emacsbugs-01 <at> cs.toronto.edu>,
 Eli Zaretskii <eliz <at> gnu.org>, Bill Wohler <wohler <at> newt.com>,
 67359 <at> debbugs.gnu.org
Subject: Re: bug#67359: 29.1;
 29.1: MH-E limited display malfunctions if nothing is matched
Date: Wed, 22 Nov 2023 11:21:29 -0500

> > > From: Chris Siebenmann <cks.emacsbugs-01 <at> cs.toronto.edu>
> > > 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.