On Tue, Sep 21 2021, Alan Schmitt wrote:

> On 2021-09-21 09:42, David Bremner <david@tethera.net> writes:
>
>> That's not completely unexpected. The change in question only really fixes it for
>> unthreaded view. Try notmuch-unthreaded-from-search-current-query (bound
>> to 'U' by default).
>
> Thank you for bearing with me. I confirm that I can see messages at the
> beginning of the thread using both an unthreaded search and
> notmuch-show-only-matching-messages set to t. Unfortunately, messages
> later in the thread still result in an error:
>
> Debugger entered--Lisp error: (error "Lisp nesting exceeds
> ‘max-lisp-eval-depth’")

I'd be interested to know if changing max-lisp-eval-depth to a larger value
made difference.

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

    This variable may be risky if used as a file-local variable.

  Documentation:
  Limit on depth in ‘eval’, ‘apply’ and ‘funcall’ before error.

  This limit serves to catch infinite recursions for you before they cause
  actual stack overflow in C, which would be fatal for Emacs.
  You can safely make it considerably larger than its default value,
  if that proves inconveniently small.  However, if you increase it too far,
  Emacs could overflow the real C stack, and crash.
--8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<----8<---

e.g (set max-lisp-eval-depth 1600)

(more interesting thing is what causes such a deep recursion...)

Tomi


>
> Thanks,
>
> Alan
_______________________________________________
notmuch mailing list -- notmuch@notmuchmail.org
To unsubscribe send an email to notmuch-leave@notmuchmail.org