GNU bug report logs -
#73581
29.4; Gnus: Error doing a search on nnmaildir with gnus-search-find-grep
Previous Next
Full log
Message #41 received at 73581 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
Visuwesh <visuweshm <at> gmail.com> writes:
> [சனி ஏப்ரல் 12, 2025] Daniel Cerqueira wrote:
>
[...]
>>> I can give a shot at debugging, when I have time, if you provide the
>>> backtrace. Getting the find-grep backend to work was a goal for me, you
>>> gave me a good excuse to procrastinate from working on my thesis. ;-)
>>
>> Ahaha! Now it is giving no error. But it is also not resulting a
>> result (from a search query that I know it has matches).
>>
>> The message that I get is:
>>
>> Group nnselect:nnselect-87tt6taade.fsf contains no messages
>>
>> I also have changed this variable:
>>
>> (set 'gnus-search-default-engines
>> '((nnimap . gnus-search-imap)
>> (nnmaildir . gnus-search-find-grep)
>> (nnselect . gnus-search-nnselect)
>> ;; (nnselect . gnus-search-find-grep)
>> ))
>>
>> Maybe this variable is incorrect? What I want is for the nnmaildir
>> back-end to use find-grep.
>
> I modify that exact variable to make nnmaildir use
> gnus-search-find-grep. I forgot to pass the mandatory argument to
> forward-whitespace. Please try the patch below instead,
>
> diff --git a/lisp/gnus/gnus-search.el b/lisp/gnus/gnus-search.el
[...]
It is working. No errors. But I don't understand what functionality
you did add. Can you document this or, the meantime, tell me?
>>>> Okay. Regarding subject, I understand grep not doing it; but regarding
>>>> time, something can be done with find (it is find-grep after all). No
>>>> need or no pressure in doing it, though.
>>>
>>> I don't think we can exploit the various time statistics attached with a
>>> file to achieve what you want. A message from 2019 reports:
>>>
>>> % stat ~/mail/XXX/inbox/cur/1641645812.328064_1.astatine,U=1:2,S
>>> File: ~/mail/XXX/inbox/cur/1641645812.328064_1.astatine,U=1:2,S
>>> Size: 8420 Blocks: 24 IO Block: 4096 regular file
>>> Device: 8,4 Inode: 5774494 Links: 1
>>> Access: (0600/-rw-------) Uid: ( 1000/ viz) Gid: ( 1000/ viz)
>>> Access: 2025-04-12 13:46:05.575388637 +0530
>>> Modify: 2022-01-08 18:13:32.297967005 +0530
>>> Change: 2022-06-05 07:44:16.919565297 +0530
>>> Birth: 2022-01-08 18:13:32.297967005 +0530
>>> % grep ^Date: ~/mail/XXX/inbox/cur/1641645812.328064_1.astatine,U=1:2,S
>>> Date: Mon, 21 Jan 2019 02:14:48 -0800
>>
>> What I was thinking is using the arguments of the executable find, such
>> as atime, ctime, mtime (which one fits best?), when using a query for
>> time, such as since:3d (I believe the keyword for other queries is
>> "since:", but I am not sure of this).
>
> The problem is mtime, ctime and atime are clearly not reliable as shown
> in the example above. So we cannot rely on them to indirectly query the
> Date header.
Since "grep:" is also unable to specify to search in a mail field or in
the body, etc. I was thinking that `find` would also not be able to
search in the Date header. It does make sense. It would only search on
the attributes of the file (with mtime, ctime or atime).
Also, not that is with 'list-all-buffers function, the buffer *Buffer
List* shows this line:
* *gnus-search- 4008 Fundamental ~/Mail/
Something is missing in *gnus-search- . Maybe this is revealing a bug
that hasn't quite done damage, yet.
Have a good thesis writing :-) .
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 66 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.