[neomutt-users] server-side ('l =b <pattern>') search claims "Success", yet index not limited

[Pietro Cerutti]

On May 18 2020, 20:25 UTC, Brian Parent <bparent at ucsd.edu> wrote:
>Thanks for the effort Pietro.  At least now I know it's not a bug 
>impacting everyone.
>
>You're right, my description of my use case was simplified.  I was 
>actually using 'l ~r1- ~f torrub =b fileset',
>hence the parentheses in my debug output, vs. no parentheses in yours.
>Perhaps the lack of other search terms in my debug output is because 
>prior to capturing debug output, I run 'l ~r1- ~f torrub',
>then I update my limit to include the =b search, and grab the resulting 
>debug output.

Ah, that's something I can reproduce.

On this mailbox:
l ~r 1-            --> 6/760 (correct)
l =b release       --> 44/760 (correct)
l ~r 1- =b release --> 249/760 (NOT correct)

249 is the number of entries in the index, since I'm using a threaded 
view. Without threads, I get 760/760.

I am not sure how client-side and server-side limits are supposed to 
work together.
I have opened https://github.com/neomutt/neomutt/issues/2349 to see if 
it can be tracked down some further.

>I guess I'll see if I can build from git directly, rather than via 
>macports to see whether that helps.

No need for that - thanks!

>
>Re:
>> From: Pietro Cerutti <gahr at gahr.ch>
>> Date: Mon, 18 May 2020 07:49:00 +0000
>> Subject: Re: [neomutt-users] server-side ('l =b <pattern>') search claims
>>  "Success", yet index not limited
>> To: Brian Parent <bparent at ucsd.edu>
>> Cc: neomutt-users at neomutt.org
>>
>> On May 17 2020, 17:11 UTC, Brian Parent <bparent at ucsd.edu> wrote:
>>
>> Hi Brian,
>>
>> > Using ~b to for body searches correctly displays the limited matching
>> > set of messages in the index,
>> > but using =b for the same search string results in displaying all
>> > messages in the index.
>> > Using debug level 5, the search claims "Success".
>> > Indeed, when the search fails, the index list is empty, as expected.
>> > So, the failure doesn't appear to be the search itself, but in the
>> > resulting index display.
>> >
>> > The problem exists in NeoMutt 20200424, but not in NeoMutt 20180716.
>>
>> I cannot reproduce this neither with my usual setup nor with an empty config
>> file, running 20200424 or master.
>>
>> Running the limit command "l=b contributors" on this very mailbox gives me
>> back a view limited to 33 messages, as also confirmed by the status bar:
>> [Msgs:33/758 Post:1 5.2M]
>>
>> > I installed 20200424 using MacPorts "port install neomutt +gdbm +sasl"
>> >
>> > After noticing the failure, I restored the previous (20180716) version,
>> > and the problem went away.
>> >
>> > Here's the relevant debug output ('l =b fileset'):
>> >
>> > 	2020-05-17 09:26:57]<M> mutt_pattern_func() Compiling search pattern...
>> > 	[2020-05-17 09:26:57]<2> mutt_socket_write_d() 8> a0015 UID SEARCH (BODY "fileset")
>> > 	[2020-05-17 09:26:57]<5> mutt_socket_readln_d() 8< * SEARCH 55168 55660 55662 55663 55664 55666 55668 55672 55675 92292 109204 146858 151348 155782 175552 175553 175558 175588 175590 175600 175601 175659 175663 175670 175689 175701 175702
>> > 	[2020-05-17 09:26:57]<2> cmd_parse_search() Handling SEARCH
>> > 	[2020-05-17 09:26:57]<5> mutt_socket_readln_d() 8< a0015 OK SEARCH completed (Success)
>> > 	[2020-05-17 09:26:57]<3> imap_cmd_step() IMAP queue drained
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 0
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 0
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 100
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 200
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 300
>> > 	...
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 3000
>> > 	[2020-05-17 09:26:57]<4> mutt_progress_update() updating progress: 3100
>> > 	[2020-05-17 09:26:57]<M> mutt_index_menu() To view all messages, limit to "all"
>>
>> Here's my excerpt:
>>
>> [2020-05-18 07:24:20]<M> mutt_pattern_func() Compiling search pattern...
>> [2020-05-18 07:24:20]<2> mutt_socket_write_d() 5> a0089 UID SEARCH BODY "contributors"
>> [2020-05-18 07:24:20]<5> mutt_socket_readln_d() 5< * SEARCH 3 16 20 25 27 28 33 46 97 112 126 134 135 136 137 148 167 181 185 207 258 285 313 323 342 640 643 656 665 666 714 716 741 742 747
>> [2020-05-18 07:24:20]<2> cmd_parse_search() Handling SEARCH
>> [2020-05-18 07:24:20]<5> mutt_socket_readln_d() 5< a0089 OK Search completed (0.126 + 0.000 + 0.125 secs).
>> [2020-05-18 07:24:20]<3> imap_cmd_step() IMAP queue drained
>> [2020-05-18 07:24:20]<4> mutt_progress_update() updating progress: 0
>> [2020-05-18 07:24:20]<4> mutt_progress_update() updating progress: 0
>> [2020-05-18 07:24:20]<M> mutt_index_menu() To view all messages, limit to "all"
>>
>> One thing I notice is that your NeoMutt issues
>>     UID SEARCH (BODY "term")
>>
>> while mine issues
>>     UID SEARCH BODY "term"
>>
>> which suggets your NeoMutt thinks you're builing a pattern composed of
>> several terms, e.g., UID SEARCH (OR BODY "foo" BODY "bar").
>>
>> I haven't found a way to reproduce the simple (BODY "term") phrase, though.
>>
>> Two questions:
>>
>> Are <l =b fileset> and <UID SEARCH (BODY "fileset")> *exactly* what you type
>> and what you get in the logs, or did you simplify the actual use case?
>>
>> Do you / does MacPorts have any local patches on top of the vanilla NeoMutt
>> distribution?
>>
>> --
>> Pietro Cerutti
>
>-- 
>Brian Parent
>Information Technology Services Department
>IT Infrastructure Operations Group
>Workplace, Internal, Research, and Educational Platforms (WIRE) team
>UC San Diego
>(858) 534-6090

-- 
Pietro Cerutti