performance in emacs displaying a huge thread

performance in emacs displaying a huge thread

[Alan Schmitt]

Hello,

I have some performance issues when displaying a huge thread, like this:

September 07 [13/5767] 

It takes forever to display (I've waited a few minutes and it was still
stuck). I know it's a lot of messages, so is there a way to just display
the 13 that match? Or to limit the total number of messages displayed?

Thanks,

Alan

Re: performance in emacs displaying a huge thread

[Örjan Ekeberg]

Hi Alan,

Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
> September 07 [13/5767] 
>
> It takes forever to display (I've waited a few minutes and it was still
> stuck). I know it's a lot of messages, so is there a way to just display
> the 13 that match? Or to limit the total number of messages displayed?

I think opening the thread with C-U RET instead of RET does exactly
that, i.e. only shows the matching messages.

In less extreme cases, using tree view (ALT-RET) may be an option since
it does not have to format the contents of the entire thread.

I have a vague recollection that someone pointed out that it is the
indentation that takes most of the time and that turning off indentation
speeds up the display of huge threads.

/Örjan

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

Hi Örjan,

On 2020-01-15 21:15, Örjan Ekeberg <ekeberg@kth.se> writes:

> I think opening the thread with C-U RET instead of RET does exactly
> that, i.e. only shows the matching messages.
>
> In less extreme cases, using tree view (ALT-RET) may be an option since
> it does not have to format the contents of the entire thread.

Both work great, thanks. I did not think of using a universal argument.

> I have a vague recollection that someone pointed out that it is the
> indentation that takes most of the time and that turning off indentation
> speeds up the display of huge threads.

I'll give it a try. Thanks again,

Alan

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

Hello,

On 2020-01-15 21:15, Örjan Ekeberg <ekeberg@kth.se> writes:

> I have a vague recollection that someone pointed out that it is the
> indentation that takes most of the time and that turning off indentation
> speeds up the display of huge threads.

I've been trying this by setting:

  (setq notmuch-show-indent-messages-width 0)
  (setq-default notmuch-show-indent-content nil)

but huge threads still take forever to show. Are there other settings
I should try?

Thanks,

Alan

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> On 2020-01-15 21:15, Örjan Ekeberg <ekeberg@kth.se> writes:
>
>> I have a vague recollection that someone pointed out that it is the
>> indentation that takes most of the time and that turning off indentation
>> speeds up the display of huge threads.
>
> I've been trying this by setting:
>
>   (setq notmuch-show-indent-messages-width 0)
>   (setq-default notmuch-show-indent-content nil)
>
> but huge threads still take forever to show. Are there other settings
> I should try?

With commit 37f84d6d2 (only in master currently), much larger threads
should be displayable in unthreaded view, e.g using M-x
notmuch-unthreaded

d

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 835 bytes --]

Hello,

On 2021-08-01 23:11, David Bremner <david@tethera.net> writes:

> With commit 37f84d6d2 (only in master currently), much larger threads
> should be displayable in unthreaded view, e.g using M-x
> notmuch-unthreaded

I just updated to 0.32.3, and I confirm a message is displayed quite
fast (if I set notmuch-show-only-matching-messages to t). However, if I
choose a message too deep in the thread, I get an error 

show-insert-thread: Lisp nesting exceeds ‘max-lisp-eval-depth’

and the message is not displayed.

After experimenting a bit, it seems this is happening when the messages
in the thread are encrypted. I don’t seem to be able to reproduce this
error with messages that are not encrypted.

Could something special be happening with long threads of encrypted
messages?

Thanks,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2021-08-01 23:11, David Bremner <david@tethera.net> writes:
>
>> With commit 37f84d6d2 (only in master currently), much larger threads
>> should be displayable in unthreaded view, e.g using M-x
>> notmuch-unthreaded
>
> I just updated to 0.32.3, and I confirm a message is displayed quite
> fast (if I set notmuch-show-only-matching-messages to t). However, if I
> choose a message too deep in the thread, I get an error 
>
> show-insert-thread: Lisp nesting exceeds ‘max-lisp-eval-depth’
>
> and the message is not displayed.

The commit I mentioned is not in 0.32.3.

d

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 238 bytes --]

On 2021-08-20 09:55, David Bremner <david@tethera.net> writes:

> The commit I mentioned is not in 0.32.3.

Ah, sorry, I thought a release included what was in master at that time.
I guess I should wait for 0.33?

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> On 2021-08-20 09:55, David Bremner <david@tethera.net> writes:
>
>> The commit I mentioned is not in 0.32.3.
>
> Ah, sorry, I thought a release included what was in master at that time.
> I guess I should wait for 0.33?
>

Right, it should be just a few weeks.

d

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 2677 bytes --]

Hello,

I’m on notmuch 0.33.1 and I’m still having issues displaying messages in
long threads when the messages are encrypted. I have such a thread with
more than 600 messages, and when I do the following:
- search for the messages
- run notmuch-tree-from-search-current-query

I get an error (I only show the top of the backtrace, it’s really huge):

Debugger entered--Lisp error: (error "Lisp nesting exceeds ‘max-lisp-eval-depth’")
  apply(concat "...")
  replace-regexp-in-string("^\\([Rr]e: *\\)+" "" "...")
  notmuch-show-strip-re("...")
  notmuch-tree-format-field("subject" "%s" (:id "Mr.isFiQDKYZxD.GlhHReZivPr@polytechnique.org" :match t :excluded nil :filename ("/home/schmitta/.Maildir/o2switch/.INBOX.DeltaChat/...") :timestamp 1629630478 :date_relative "August 22" :tags ("encrypted") :crypto nil :headers (:Subject "..." :From "<alan.schmitt@polytechnique.org>" :To "***" :Date "Sun, 22 Aug 2021 11:07:58 +0000") :first nil :tree-status ("┬►" "╰" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ...) :orig-tags ("encrypted")))
  notmuch-tree-format-field-list((("tree" . "%s") ("subject" . "%s")) (:id "Mr.isFiQDKYZxD.GlhHReZivPr@polytechnique.org" :match t :excluded nil :filename ("/home/schmitta/.Maildir/o2switch/.INBOX.DeltaChat/...") :timestamp 1629630478 :date_relative "August 22" :tags ("encrypted") :crypto nil :headers (:Subject "..." :From "<alan.schmitt@polytechnique.org>" :To "***" :Date "Sun, 22 Aug 2021 11:07:58 +0000") :first nil :tree-status ("┬►" "╰" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ...) :orig-tags ("encrypted")))
  notmuch-tree-format-field((("tree" . "%s") ("subject" . "%s")) " %-54s " (:id "Mr.isFiQDKYZxD.GlhHReZivPr@polytechnique.org" :match t :excluded nil :filename ("/home/schmitta/.Maildir/o2switch/.INBOX.DeltaChat/...") :timestamp 1629630478 :date_relative "August 22" :tags ("encrypted") :crypto nil :headers (:Subject "..." :From "<alan.schmitt@polytechnique.org>" :To "***" :Date "Sun, 22 Aug 2021 11:07:58 +0000") :first nil :tree-status ("┬►" "╰" " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " " ...) :orig-tags ("encrypted")))

I can see the earlier messages in the thread, but the later ones cannot
be shown.

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello,
>
> I’m on notmuch 0.33.1 and I’m still having issues displaying messages in
> long threads when the messages are encrypted. I have such a thread with
> more than 600 messages, and when I do the following:
> - search for the messages
> - run notmuch-tree-from-search-current-query

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).\r

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 2235 bytes --]

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’")
  mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedb05>) ((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))) 197)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))) (nil ((nil ((nil nil))))))) 196)
  #f(compiled-function (tree) #<bytecode 0x155b47dedaf9>)((nil ((nil ((nil ((nil ...))))) (nil ((nil ((nil nil))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedaf9>) ((nil ((nil ((nil (...)))) (nil ((nil (...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (...)))) (nil ((nil (...))))))) 196)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))) (nil ((nil ...))))))) 195)
  #f(compiled-function (tree) #<bytecode 0x155b47dedaed>)((nil ((nil ((nil ((nil ...))) (nil ((nil ...))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedaed>) ((nil ((nil ((nil (...)) (nil (...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (...)) (nil (...))))))) 195)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...) (nil ...))))))) 194)
  #f(compiled-function (tree) #<bytecode 0x155b47dedae1>)((nil ((nil ((nil ((nil ...) (nil ...))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedae1>) ((nil ((nil ((nil (... ...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (... ...))))))) 194)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))))) 193)

I searched through our conversations and I found references to
notmuch-show-single-message, but I don’t seem to find how to set it
(it’s not known when I search for it). Has it been renamed?

Thanks,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> 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’")
>   mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedb05>) ((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))))
>   notmuch-show-insert-thread(((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))) 197)
>   notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))) (nil ((nil ((nil nil))))))) 196)

I don't really understand how you got here. For me, if I type U from
notmuch-search to get an unthreaded view, then <return> just shows the
single message, and "notmuch-show-insert-tree" is not called.

In this way I can view arbitrary messages threads of up to 1024 in
length. I didn't test with encrypted messages, maybe that changes
something.

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 2498 bytes --]

Hello,

On 2021-09-21 12:38, David Bremner <david@tethera.net> writes:

> Alan Schmitt <alan.schmitt@polytechnique.org> writes:
>
>> 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’")
>>   mapc(#f(compiled-function (tree) #<bytecode 0x155b47dedb05>) ((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))))
>>   notmuch-show-insert-thread(((nil ((nil ((nil (...)))))) (nil ((nil ((nil nil)))))) 197)
>>   notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))) (nil ((nil ((nil nil))))))) 196)
>
> I don't really understand how you got here. For me, if I type U from
> notmuch-search to get an unthreaded view, then <return> just shows the
> single message, and "notmuch-show-insert-tree" is not called.
>
> In this way I can view arbitrary messages threads of up to 1024 in
> length. I didn't test with encrypted messages, maybe that changes
> something.

I can view a thread with more than 7000 messages (with
show-only-matching-messages to t) if they are not encrypted. In fact I
already could with 0.32 if I remember correctly. The fact that messages
are encrypted seems to matter here.

If it matters, here is the bottom of the debug stack:

  notmuch-show-insert-thread(((nil ((nil ((nil nil) (nil (... ...))))))) 1)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil nil) (nil ...))))))) 0)
  #f(compiled-function (tree) #<bytecode 0x155b49d5fc55>)((nil ((nil ((nil ((nil nil) (nil ...))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b49d5fc55>) ((nil ((nil ((nil (... ...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (... ...))))))) 0)
  #f(compiled-function (thread) #<bytecode 0x155b49b2e195>)(((nil ((nil ((nil (... ...))))))))
  mapc(#f(compiled-function (thread) #<bytecode 0x155b49b2e195>) (((nil ((nil ((nil ...))))))))
  notmuch-show-insert-forest((((nil ((nil ((nil ...))))))))
  notmuch-show--build-buffer()
  notmuch-show("id:Mr.ye1AxFHsd2E.Vd_oS17awSv@polytechnique.org")
  notmuch-tree-show-message-out()
  notmuch-tree-show-message(nil)
  funcall-interactively(notmuch-tree-show-message nil)
  call-interactively(notmuch-tree-show-message nil nil)
  command-execute(notmuch-tree-show-message)

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[Tomi Ollila]

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

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 1138 bytes --]

On 2021-09-21 21:27, Tomi Ollila <tomi.ollila@iki.fi> writes:

> I'd be interested to know if changing max-lisp-eval-depth to a larger value
> made difference.
> 
> e.g (set max-lisp-eval-depth 1600)

Thank you for the suggestion. I tried with 1600, and I get a different
error (and the numbers are larger now).

Debugger entered--Lisp error: (error "Variable binding depth exceeds max-specpdl-size")
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))))) 394)
  #f(compiled-function (tree) #<bytecode 0x155b49be0bc1>)((nil ((nil ((nil ((nil ...))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b49be0bc1>) ((nil ((nil ((nil (...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (...))))))) 394)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))))) 393)
  #f(compiled-function (tree) #<bytecode 0x155b48328d89>)((nil ((nil ((nil ((nil ...))))))))
  mapc(#f(compiled-function (tree) #<bytecode 0x155b48328d89>) ((nil ((nil ((nil (...))))))))
  notmuch-show-insert-thread(((nil ((nil ((nil (...))))))) 393)
  notmuch-show-insert-tree((nil ((nil ((nil ((nil ...))))))) 392)

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[Tomi Ollila]

On Wed, Sep 22 2021, Alan Schmitt wrote:

> On 2021-09-21 21:27, Tomi Ollila <tomi.ollila@iki.fi> writes:
>
>> I'd be interested to know if changing max-lisp-eval-depth to a larger value
>> made difference.
>> 
>> e.g (set max-lisp-eval-depth 1600)
>
> Thank you for the suggestion. I tried with 1600, and I get a different
> error (and the numbers are larger now).
>
> Debugger entered--Lisp error: (error "Variable binding depth exceeds
> max-specpdl-size")

Now it failed due to exceeding max-specpdl-size (which seems to be 1600
by default)

W/o knowing better I'd try (setq max-specpdl-size 3200) now...

(further tries could be enlarging the values discussed 10-fold...)

Tomi

>
> Best,
>
> Alan

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 782 bytes --]

Hello,

On 2021-09-22 11:25, Tomi Ollila <tomi.ollila@iki.fi> writes:

>>> e.g (set max-lisp-eval-depth 1600)
>>
>> Thank you for the suggestion. I tried with 1600, and I get a different
>> error (and the numbers are larger now).
>>
>> Debugger entered--Lisp error: (error "Variable binding depth exceeds
>> max-specpdl-size")
>
> Now it failed due to exceeding max-specpdl-size (which seems to be 1600
> by default)
>
> W/o knowing better I'd try (setq max-specpdl-size 3200) now...
>
> (further tries could be enlarging the values discussed 10-fold...)

Thank you for the suggestion!

Setting both to 3200 work for this particular thread (and it’s quite
fast too…). I’m really curious why there is that many recursive calls,
though.

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

>
> I can view a thread with more than 7000 messages (with
> show-only-matching-messages to t) if they are not encrypted. In fact I
> already could with 0.32 if I remember correctly. The fact that messages
> are encrypted seems to matter here.

I've been unable to replicate this deep recursion. Whenever I'm in
unthreaded search view, I have one message summary on every line, and
when I trace through notmuch-show-insert-tree,

  (let ((msg (car tree))
	(replies (cadr tree)))

always assigns nil (empty list) to replies.  That means my call stack
has exactly one instance of notmuch-show-insert-tree.

>
> If it matters, here is the bottom of the debug stack:
>
>   notmuch-show-insert-thread(((nil ((nil ((nil nil) (nil (... ...))))))) 1)
>   notmuch-show-insert-tree((nil ((nil ((nil ((nil nil) (nil ...))))))) 0)
>   #f(compiled-function (tree) #<bytecode 0x155b49d5fc55>)((nil ((nil ((nil ((nil nil) (nil ...))))))))
>   mapc(#f(compiled-function (tree) #<bytecode 0x155b49d5fc55>) ((nil ((nil ((nil (... ...))))))))
>   notmuch-show-insert-thread(((nil ((nil ((nil (... ...))))))) 0)
>   #f(compiled-function (thread) #<bytecode 0x155b49b2e195>)(((nil ((nil ((nil (... ...))))))))
>   mapc(#f(compiled-function (thread) #<bytecode 0x155b49b2e195>) (((nil ((nil ((nil ...))))))))
>   notmuch-show-insert-forest((((nil ((nil ((nil ...))))))))
>   notmuch-show--build-buffer()
>   notmuch-show("id:Mr.ye1AxFHsd2E.Vd_oS17awSv@polytechnique.org")
>   notmuch-tree-show-message-out()
>   notmuch-tree-show-message(nil)
>   funcall-interactively(notmuch-tree-show-message nil)
>   call-interactively(notmuch-tree-show-message nil nil)
>   command-execute(notmuch-tree-show-message)

On possibility is that there some old version of the code that you are
running.  Inside notmuch-show-insert-tree, the variable
notmuch-show-single-message should be 't', whether called from regular
tree-mode or an unthreaded search.

As an experiment, you could try redefining

(defun notmuch-show-insert-tree (tree depth)
  "Insert the message tree TREE at depth DEPTH in the current thread."
  (let ((msg (car tree))
	(replies (cadr tree)))
    (message "nreplies %d flag %s" (length replies) notmuch-show-single-message)
    ;; We test whether there is a message or just some replies.
    (when msg
      (notmuch-show-insert-msg msg depth))
    (notmuch-show-insert-thread replies (1+ depth))))

this will log the number of replies and flag value. For me, it logs

"nreplies 0 flag t"

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 429 bytes --]

Hello David,

I found the source of the issue, and I would like to apologize because
it’s fully my fault. I’ve realized I was not using the elisp code from
the package installed using my package manager, but one installed using
straight that was pinned to an old version. I simply switched to the
release branch, and now everything works out of the box.

I’m very sorry for the time lost.

Best regards,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

> Hello David,
>
> I found the source of the issue, and I would like to apologize because
> it’s fully my fault. I’ve realized I was not using the elisp code from
> the package installed using my package manager, but one installed using
> straight that was pinned to an old version. I simply switched to the
> release branch, and now everything works out of the box.
>
> I’m very sorry for the time lost.
>

That will teach me not to ask people to check M-x notmuch-version!

d

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 994 bytes --]

Hello,

On 2021-09-24 20:33, David Bremner <david@tethera.net> writes:

> That will teach me not to ask people to check M-x notmuch-version!

I did at the time, and it reported "0.33.1". So I investigated a bit.

If I search for the `notmuch-version' function, I find it in 
~/.emacs-configs/doom-emacs/.local/straight/repos/notmuch/emacs/notmuch-lib.el
as expected

But then, if I look up the variable `notmuch-emacs-version', it is
picked up from
/usr/share/emacs/site-lisp/notmuch-version.el

so this is why the discrepancy was not reported.

The surprising thing is that there is not file 
~/.emacs-configs/doom-emacs/.local/straight/repos/notmuch/emacs/notmuch-version.el,
just a file
~/.emacs-configs/doom-emacs/.local/straight/repos/notmuch/emacs/notmuch-version.el.tmpl
so this is probably why the global file is chosen.

I have no idea why this is happening… It could be a doom or straight
bug… If you think so as well, I will report it.

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[David Bremner]

[-- Attachment #1: Type: text/plain, Size: 923 bytes --]

Alan Schmitt <alan.schmitt@polytechnique.org> writes:

>
> The surprising thing is that there is not file 
> ~/.emacs-configs/doom-emacs/.local/straight/repos/notmuch/emacs/notmuch-version.el,
> just a file
> ~/.emacs-configs/doom-emacs/.local/straight/repos/notmuch/emacs/notmuch-version.el.tmpl
> so this is probably why the global file is chosen.
>
> I have no idea why this is happening… It could be a doom or straight
> bug… If you think so as well, I will report it.

I think it is a bug in doom or straight, or at least an assumption that
turns out to be wrong. They are assuming the elisp is runnable from git,
but in fact it needs to run make to create notmuch-version.el. I think
the straight recipe could specify a ":pre-build" step to build
notmuch-version.el. I attach a Makefile snippet that shows how to build
the file without running configure. You'd still need make, git, and sed. 


[-- Attachment #2: Standalone.mk --]
[-- Type: application/octet-stream, Size: 365 bytes --]

VERSION:=$(shell git describe --abbrev=7 --match '[0-9.]*'|sed -e s/_/~/ -e s/-/+/ -e s/-/~/)
# for released versions: 
# VERSION:=$(shell cat version.txt)
ELPA_VERSION:=$(subst ~,_,$(VERSION))

emacs/notmuch-version.el: emacs/notmuch-version.el.tmpl
	sed -e 's/%AG%/Generated file (from $(<F)) -- do not edit!/' \
	    -e 's/%VERSION%/"$(ELPA_VERSION)"/' $< > $@


[-- Attachment #3: Type: text/plain, Size: 0 bytes --]

Re: performance in emacs displaying a huge thread

[Alan Schmitt]

[-- Attachment #1.1: Type: text/plain, Size: 682 bytes --]

Hello,

On 2021-09-25 10:26, David Bremner <david@tethera.net> writes:

> I think it is a bug in doom or straight, or at least an assumption that
> turns out to be wrong. They are assuming the elisp is runnable from git,
> but in fact it needs to run make to create notmuch-version.el. I think
> the straight recipe could specify a ":pre-build" step to build
> notmuch-version.el. I attach a Makefile snippet that shows how to build
> the file without running configure. You'd still need make, git, and sed. 

For the record, this was fixed in doom in this commit:
https://github.com/hlissner/doom-emacs/commit/473eda795a1fcfd5562798bab6f79f72b0cebb6f

Best,

Alan

[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 528 bytes --]

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]