Re: show a single message in a huge thread

[Tomi Ollila <tomi.ollila@iki.fi>]

On Wed, Jun 02 2021, David Bremner wrote:

> David Bremner <david@tethera.net> writes:
>
>> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>>
>>> Hello,
>>>
>>> On 2021-06-01 15:33, David Bremner <david@tethera.net> writes:
>>>
>>>>> Is this a bug of notmuch-emacs? Is there a way to display a single
>>>>> message independently of its context?
>>>>>
>>>>
>>>> I'm not sure what the best UI is, but here is a start:
>>>>
>>>> (defun notmuch-show-single-message (query)
>>>>   (interactive "sQuery: ")
>>>>   (message query)
>>>>   (let ((notmuch-show-indent-messages-width 0)
>>>>         (notmuch-show-only-matching-messages t))
>>>>     (notmuch-show query)))
>>>
>>> Thank you for the suggestion, unfortunately I get a very similar error.
>>> I found the id of the message I want, and when I run this function, I
>>> get this backtrace.
>>>
>>
>> The code I posted worked fine for me for one message from a thread of
>> 323 messages. It could be a I need a really giant thread to test, or
>> perhaps the structure of the individual messages matters also. The long
>> threads I have are from Debian mailing lists, so the message structure
>> tests to be be mainly one part of plain text.
>
> I played with this some more, and I think I understand what the issue
> is, although I still cannot duplicate the crash.  By unless given the

max-lisp-eval-depth is a variable defined in ‘C source code’.
Its value is 800

Started second emacs, tried to set max-lisp-eval-depth to 10 
(changed to 100, cannot go lower) then run notmuch 
(ya! you can do that -- no go w/ vm or gnus!) .
I have too short threads to get that crashing :/ but perhaps
someone else(tm) is luckier... ;/

Tomi


> "--part" option the CLI returns the whole thread structure, even if it
> does not populate it. So there is a big tree of empty lists, and
> recursively traversing this tree is what is crashing.  In principle
> passing "--part=0" to the CLI should turn off this behaviour, but I
> don't know how much needs to be changed on the emacs side to display the
> result properly.