some issues with emacs 25

some issues with emacs 25

[Matthew Lear]

Hi,
I switched to trying emacs 25 (25.1) with notmuch the other day. I
really like some of the improvements that have been made (in particular,
SHR seems to do a much nicer and quicker job of rendering html emails).
However, things came a little unstuck when I tried to reply to an email
with notmuch. I have notmuch set to discourage plain text simply because
I deal with a lot of email which is sent in html (people frequently
in-line tables, images etc) and when I replied, notmuch generated the
following in the new message buffer:

> !!! Bodypart handler `notmuch-show-insert-part-text/html' threw an error:
> !!! Window is dedicated to ‘*unsent mail to user@domain.com*’
>

Errors like these are generated by replying from either notmuch-tree or
notmuch-show.

I'd made no changes to my .emacs before switching to 25 and just to
check, I switched back to 24 (24.5) and I could reply to the same email
without any trouble.

I'm of the opinion that this is probably some sort of set up /
configuration issue specific to 25, but I'm quite surprised. I don't
have many settings for handling html stuff:

(setq mm-text-html-renderer 'shr)
(setq shr-inhibit-images nil)
(setq mime-view-text/html-previewer 'shr)
(setq mm-inline-text-html-with-images t)
(setq notmuch-multipart/alternative-discouraged '("text/plain"))

Is this reproducible for anyone else with notmuch from git/master as of
today?

Cheers,
--  Matt

Re: some issues with emacs 25

[Matt Armstrong]

Matthew Lear <matt@bubblegen.co.uk> writes:

> Hi,
> I switched to trying emacs 25 (25.1) with notmuch the other day.

I'm on 25.1 as well, but haven't experienced the symptoms you describe.

>> !!! Bodypart handler `notmuch-show-insert-part-text/html' threw an error:
>> !!! Window is dedicated to ‘*unsent mail to user@domain.com*’
>
> Errors like these are generated by replying from either notmuch-tree or
> notmuch-show.

Below I tried replying from notmuch-show.

> I'm of the opinion that this is probably some sort of set up /
> configuration issue specific to 25, but I'm quite surprised. I don't
> have many settings for handling html stuff:
>
> (setq mm-text-html-renderer 'shr)
> (setq shr-inhibit-images nil)
> (setq mime-view-text/html-previewer 'shr)
> (setq mm-inline-text-html-with-images t)
> (setq notmuch-multipart/alternative-discouraged '("text/plain"))
>
> Is this reproducible for anyone else with notmuch from git/master as of
> today?

Matt, I couldn't resist helping another, Matt, so I copy-pasted your
setq incantations, executed them (thus "poisoning" my precious Emacs!),
and was able to initiate replies to several emails.  Some were
multipart/mixed with HTML alternatives, some (like yours) were
text/plain.

I'm running recent-ish notmuch binaries from git/master, running even
fresher elisp from git/master (I think I pulled last night).

It may be necessary for you to play around with the various Emacs
options to eliminate site specific stuff: -Q, -q, etc.  Here at work a
bunch of people are moving to Emacs 25 and a common theme is some old
package in their setup somehow conflicts with Emacs 25 (e.g. it shadows
something that is now part of Emacs but has changed in subtle ways,
etc.).

Re: some issues with emacs 25

[Matthew Lear]

> On 28 Oct 2016, at 01:52, Matt Armstrong <marmstrong@google.com> wrote:
> 
> Matthew Lear <matt@bubblegen.co.uk> writes:
> 
>> Hi,
>> I switched to trying emacs 25 (25.1) with notmuch the other day.
> 
> I'm on 25.1 as well, but haven't experienced the symptoms you describe.

Thanks Matt. I feel reassured! :-) I will commence with trying to figure out what is causing the problem. I've seen some weirdness with margins when viewing HTML messages too. Maybe that's some kind of bizarre toolkit thing... Anyway, thanks a lot for testing and for confirming that there's no problem.
Cheers,
  Matt

Re: some issues with emacs 25

[Matthew Lear]

On 28/10/16 22:34, Matthew Lear wrote:
> 
> I will commence with trying to figure out what is causing the problem. I've seen some weirdness with margins when viewing HTML messages too. Maybe that's some kind of bizarre toolkit thing... Anyway, thanks a lot for testing and for confirming that there's no problem.

From what I can tell, this is purely caused by using:

(setq notmuch-mua-compose-in 'new-frame)
or
(setq notmuch-mua-compose-in 'new-window)

when using (setq mm-text-html-renderer 'shr)

If I keep shr and use (setq notmuch-mua-compose-in 'current-window) or
remove this setting completely (to get the default behaviour), there is
no problem in replying to an html message and the html text being quoted.

If I switch to using different values of mm-text-html-renderer such as
w3m, links, lynx or html2text there is no problem replying when using
a new-frame or new-window via notmuch-mua-compose-in.

Seems like the problem I've seen is purely limited to using
mm-text-html-renderer equal to 'shr along with notmuch settings to
compose in either a new frame or a new window.

I've tested this with a .emacs of only a few lines and am convinced.

Please can this be verified by somebody else?

Cheers,
--  Matt

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> On 28/10/16 22:34, Matthew Lear wrote:
>> 
>> I will commence with trying to figure out what is causing the problem. I've seen some weirdness with margins when viewing HTML messages too. Maybe that's some kind of bizarre toolkit thing... Anyway, thanks a lot for testing and for confirming that there's no problem.
>
> From what I can tell, this is purely caused by using:
>
> (setq notmuch-mua-compose-in 'new-frame)
> or
> (setq notmuch-mua-compose-in 'new-window)

Yes, I can replicate this bug in emacs 25.1 by

1) ./devel/try-emacs-mua -q

2) (setq notmuch-mua-compose-in 'new-frame)

3) reply to an html only message.


If I M-x toggle-debug-on-error I get a backtrace ending in

set-window-buffer(nil #<buffer  *temp*-321945>)
shr-pixel-column
shr-string-pixe-width
shr-insert-document
notmuch-show--insert-part-text/html-shr

I can't find an html only public-message so far to give a full
backtrace.

Re: some issues with emacs 25

[Matthew Lear]

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

On 09/11/16 23:55, David Bremner wrote:
> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>> On 28/10/16 22:34, Matthew Lear wrote:
>>> I will commence with trying to figure out what is causing the problem. I've seen some weirdness with margins when viewing HTML messages too. Maybe that's some kind of bizarre toolkit thing... Anyway, thanks a lot for testing and for confirming that there's no problem.
>> From what I can tell, this is purely caused by using:
>>
>> (setq notmuch-mua-compose-in 'new-frame)
>> or
>> (setq notmuch-mua-compose-in 'new-window)
> Yes, I can replicate this bug in emacs 25.1 by
>
> 1) ./devel/try-emacs-mua -q
>
> 2) (setq notmuch-mua-compose-in 'new-frame)
>
> 3) reply to an html only message.
>
>
> If I M-x toggle-debug-on-error I get a backtrace ending in
>
> set-window-buffer(nil #<buffer  *temp*-321945>)
> shr-pixel-column
> shr-string-pixe-width
> shr-insert-document
> notmuch-show--insert-part-text/html-shr
>
> I can't find an html only public-message so far to give a full
> backtrace.
If it helps, here is some text in *bold *with some changes in red that
you can test with :-D

[-- Attachment #2: Type: text/html, Size: 1737 bytes --]

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> On 09/11/16 23:55, David Bremner wrote:
>> I can't find an html only public-message so far to give a full
>> backtrace.
> If it helps, here is some text in *bold *with some changes in red that
> you can test with :-D

FWIW, this doesn't trigger the bug with default settings + (setq
notmuch-mua-compose-in 'new-window) because it has a text part.

Re: some issues with emacs 25

[David Bremner]

David Bremner <david@tethera.net> writes:

> Yes, I can replicate this bug in emacs 25.1 by
>
> 1) ./devel/try-emacs-mua -q
>
> 2) (setq notmuch-mua-compose-in 'new-frame)
>
> 3) reply to an html only message.
>
> If I M-x toggle-debug-on-error I get a backtrace ending in
>
> set-window-buffer(nil #<buffer  *temp*-321945>)
> shr-pixel-column
> shr-string-pixe-width
> shr-insert-document
> notmuch-show--insert-part-text/html-shr
>

I have reported https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24950
upstream. We'll see if they agree it's bug in shr.

d

Re: some issues with emacs 25

[David Bremner]

David Bremner <david@tethera.net> writes:

> David Bremner <david@tethera.net> writes:
>
>> Yes, I can replicate this bug in emacs 25.1 by
>>
>> 1) ./devel/try-emacs-mua -q
>>
>> 2) (setq notmuch-mua-compose-in 'new-frame)
>>
>> 3) reply to an html only message.
>>
>> If I M-x toggle-debug-on-error I get a backtrace ending in
>>
>> set-window-buffer(nil #<buffer  *temp*-321945>)
>> shr-pixel-column
>> shr-string-pixe-width
>> shr-insert-document
>> notmuch-show--insert-part-text/html-shr
>>
>
> I have reported https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24950
> upstream. We'll see if they agree it's bug in shr.

This bug will be fixed in the next release of emacs 25, so I'm tagging
it fixed.

Re: some issues with emacs 25

[Matthew Lear]

On 20/11/16 20:01, David Bremner wrote:
>> I have reported https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24950
>> upstream. We'll see if they agree it's bug in shr.
> 
> This bug will be fixed in the next release of emacs 25, so I'm tagging
> it fixed.

I can confirm that it is indeed fixed. I'm not able to reproduce it with
the latest emacs 25 from git.
Thanks for raising it with upstream, David.
Cheers,
--  Matt

Re: some issues with emacs 25

[Matthew Lear]

On 22/11/16 14:24, Matthew Lear wrote:
> I can confirm that it is indeed fixed. I'm not able to reproduce it with
> the latest emacs 25 from git.

Unfortunately, it seems I was too hasty in confirming this.
For some reason unknown to me, replying to the html in some
multipart/alternative works fine, but others cause the same error to be
thrown. I've also seen the error occur when replying to a
multipart/mixed message, too.

Even more bizarrely, I'm currently looking at a thread with two emails
where both are multipart/alternative and contain text/plain and
text/html parts, and replying to the first message triggers the
error/bug but replying to the second message does not. I can't see any
formatting difference between the two.

Sorry, but it would appear as though there is still some work needed to
resolve this in it's entirety. I suppose it's likely that this could be
an emacs-25 issue, but what I mentioned above makes no sense to me so I
can't say for sure.

I'd happily post some debug info to help analyse this if somebody could
give me a few pointers about what would be needed and the emacs-fu
needed to generate this.

Cheers,
--  Matt

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:


> I'd happily post some debug info to help analyse this if somebody could
> give me a few pointers about what would be needed and the emacs-fu
> needed to generate this.
>
> Cheers,
> --  Matt


In a fresh emacs, can you generate an error using the recipe in

    https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24950 ?

d

Re: some issues with emacs 25

[Matthew Lear]

On 23/11/16 11:57, David Bremner wrote:
> In a fresh emacs, can you generate an error using the recipe in
> 
>     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=24950 ?

No. I can evaluate the recipe ok and eval of the last line yields:
10 (#o12, #xa, ?\C-j)

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

>
> I'd happily post some debug info to help analyse this if somebody could
> give me a few pointers about what would be needed and the emacs-fu
> needed to generate this.
>

I think the best thing at this point would be to find (or create)
another public message where you can duplicate the problem.

d

Re: some issues with emacs 25

[Matthew Lear]

On 03/12/16 01:58, David Bremner wrote:
> Matthew Lear <matt@bubblegen.co.uk> writes:
> 
>>
>> I'd happily post some debug info to help analyse this if somebody could
>> give me a few pointers about what would be needed and the emacs-fu
>> needed to generate this.
>>
> 
> I think the best thing at this point would be to find (or create)
> another public message where you can duplicate the problem.

I've sent two test emails directly to David for analysis.
--  Matt

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> On 03/12/16 01:58, David Bremner wrote:
>> Matthew Lear <matt@bubblegen.co.uk> writes:
>> 
>>>
>>> I'd happily post some debug info to help analyse this if somebody could
>>> give me a few pointers about what would be needed and the emacs-fu
>>> needed to generate this.
>>>
>> 
>> I think the best thing at this point would be to find (or create)
>> another public message where you can duplicate the problem.
>
> I've sent two test emails directly to David for analysis.
> --  Matt

So I _finally_ got around to looking at these, and I think it's roughly
the same shr bug as before but some different functions.

I could actually only duplicate the bug with emacs-reply-fail-ec
message, but that was fixed by the following patch against the emacs-25
branch. Does this patch fix both failures for you?

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 6c35a33c9c..2bc37c64bd 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1993,6 +1993,9 @@ shr-pixel-buffer-width
     (if (get-buffer-window)
        (car (window-text-pixel-size nil (point-min) (point-max)))
       (save-window-excursion
+        ;; Avoid errors if the selected window is a dedicated one,
+        ;; and they just want to insert a document into it.
+        (set-window-dedicated-p nil nil)
        (set-window-buffer nil (current-buffer))
        (car (window-text-pixel-size nil (point-min) (point-max)))))))
 
@@ -2036,6 +2039,9 @@ shr-render-td-1
            (shr-indentation 0))
        (shr-descend dom))
       (save-window-excursion
+        ;; Avoid errors if the selected window is a dedicated one,
+        ;; and they just want to insert a document into it.
+        (set-window-dedicated-p nil nil)
        (set-window-buffer nil (current-buffer))
        (unless fill
          (setq natural-width

Re: some issues with emacs 25

[Matthew Lear]

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

On 18 Feb 2017 01:01, "David Bremner" <david@tethera.net> wrote:


So I _finally_ got around to looking at these, and I think it's roughly
the same shr bug as before but some different functions.

I could actually only duplicate the bug with emacs-reply-fail-ec
message, but that was fixed by the following patch against the emacs-25
branch. Does this patch fix both failures for you?

diff --git a/lisp/net/shr.el b/lisp/net/shr.el
index 6c35a33c9c..2bc37c64bd 100644
--- a/lisp/net/shr.el
+++ b/lisp/net/shr.el
@@ -1993,6 +1993,9 @@ shr-pixel-buffer-width
     (if (get-buffer-window)
        (car (window-text-pixel-size nil (point-min) (point-max)))
       (save-window-excursion
+        ;; Avoid errors if the selected window is a dedicated one,
+        ;; and they just want to insert a document into it.
+        (set-window-dedicated-p nil nil)
        (set-window-buffer nil (current-buffer))
        (car (window-text-pixel-size nil (point-min) (point-max)))))))

@@ -2036,6 +2039,9 @@ shr-render-td-1
            (shr-indentation 0))
        (shr-descend dom))
       (save-window-excursion
+        ;; Avoid errors if the selected window is a dedicated one,
+        ;; and they just want to insert a document into it.
+        (set-window-dedicated-p nil nil)
        (set-window-buffer nil (current-buffer))
        (unless fill
          (setq natural-width


Thanks David. Yes it does. After recompiling the v25 lisp with these
changes, I'm unable to reproduce the problems with both the test emails I
sent you. Wonderful :-)
Are you going to raise this with upstream?
Cheers,
 Matt

[-- Attachment #2: Type: text/html, Size: 2300 bytes --]

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:


> Thanks David. Yes it does. After recompiling the v25 lisp with these
> changes, I'm unable to reproduce the problems with both the test emails I
> sent you. Wonderful :-)
> Are you going to raise this with upstream?
> Cheers,
>  Matt

Yes, I've filed

     https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25828

Re: some issues with emacs 25

[David Bremner]

David Bremner <david@tethera.net> writes:

> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>
>> Thanks David. Yes it does. After recompiling the v25 lisp with these
>> changes, I'm unable to reproduce the problems with both the test emails I
>> sent you. Wonderful :-)
>> Are you going to raise this with upstream?
>> Cheers,
>>  Matt
>
> Yes, I've filed
>
>      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25828
>

That bug should be fixed in emacs master branch.

d

Re: some issues with emacs 25

[Matthew Lear]

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

On 4 Mar 2017 11:03, "David Bremner" <david@tethera.net> wrote:

David Bremner <david@tethera.net> writes:

> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>
>> Thanks David. Yes it does. After recompiling the v25 lisp with these
>> changes, I'm unable to reproduce the problems with both the test emails I
>> sent you. Wonderful :-)
>> Are you going to raise this with upstream?
>> Cheers,
>>  Matt
>
> Yes, I've filed
>
>      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=25828
>

That bug should be fixed in emacs master branch.

d


It was indeed fixed...that is until I updated my emacs git tree to 25.2.1.
I've given up composing emails in new frames as it's now broken again -
this time when replying to emails which have quoted/embedded html in the
body. Feels like two steps forward, one step back :-(
--  Matt

[-- Attachment #2: Type: text/html, Size: 1671 bytes --]

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:


> It was indeed fixed...that is until I updated my emacs git tree to 25.2.1.
> I've given up composing emails in new frames as it's now broken again -
> this time when replying to emails which have quoted/embedded html in the
> body. Feels like two steps forward, one step back :-(
> --  Matt

Unfortunately I don't have easy access to emacs25.2; I've been waiting
for it show up in Debian. Can you see if the relevant fix referenced in
that bug log included in 25.2? I did wonder if maybe you had a local
modification that was lost when you updated to 25.2.

d

Re: some issues with emacs 25

[Matthew Lear]

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

Hi David. Finally got back round to checking this with recent sw. Apologies
for the long delay. I can confirm that the problem still exists as before,
ie replying to my test html emails when composing the message in a new
frame throws the bodypart errors. ...But I'm not too fussed about it
because I've got used to not composing messages in new frames ;-)

I've synced my emacs.git to:
* c3ff6712ad -  (HEAD, origin/emacs-25) * lisp/net/tls.el (tls-program):
Fix :version (do not merge to master). (2017-09-14 16:38:29 -0400) <Glenn
Morris>

Emacs version is reported as 25.3.50.1.

And notmuch.git to:
* ab8b40f7 -  (HEAD -> master, origin/master, origin/HEAD) cli: make
notmuch count --exclude a boolean argument (2017-10-15 19:22:40 -0300)
<Jani Nikula>

Using the tiny .emacs below is enough to trigger the problem:

(require 'shr)
(setq mm-text-html-renderer 'shr)
(setq mime-view-text/html-previewer 'shr)
(setq mm-html-inhibit-images nil)
(setq mm-html-blocked-images nil)
(require 'notmuch)
(setq notmuch-mua-compose-in 'new-frame)
(setq notmuch-multipart/alternative-discouraged '("text/plain"))

Not sure what you'd like to do with this from here...
Cheers,
--  Matt

On Fri, Jun 30, 2017 at 1:47 PM, David Bremner <david@tethera.net> wrote:

> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>
> > It was indeed fixed...that is until I updated my emacs git tree to
> 25.2.1.
> > I've given up composing emails in new frames as it's now broken again -
> > this time when replying to emails which have quoted/embedded html in the
> > body. Feels like two steps forward, one step back :-(
> > --  Matt
>
> Unfortunately I don't have easy access to emacs25.2; I've been waiting
> for it show up in Debian. Can you see if the relevant fix referenced in
> that bug log included in 25.2? I did wonder if maybe you had a local
> modification that was lost when you updated to 25.2.
>
> d
>

[-- Attachment #2: Type: text/html, Size: 2724 bytes --]

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> I'm of the opinion that this is probably some sort of set up /
> configuration issue specific to 25, but I'm quite surprised. I don't
> have many settings for handling html stuff:
>
> (setq mm-text-html-renderer 'shr)
> (setq shr-inhibit-images nil)
> (setq mime-view-text/html-previewer 'shr)
> (setq mm-inline-text-html-with-images t)
> (setq notmuch-multipart/alternative-discouraged '("text/plain"))
>
> Is this reproducible for anyone else with notmuch from git/master as of
> today?

According to emacs upstream, this problem (or at least my reduced test
case) is fixed in emacs 26.1

      https://debbugs.gnu.org/cgi/bugreport.cgi?bug=29273

Can you confirm that?

Re: some issues with emacs 25

[Matthew Lear]

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

I can trigger the bug if I discard text/plain though. Did you try that? 
-------- Original message --------From: David Bremner <david@tethera.net> Date: 11/11/2016  11:40  (GMT+00:00) To: Matthew Lear <matt@bubblegen.co.uk>, Matt Armstrong <marmstrong@google.com> Cc: notmuch@notmuchmail.org Subject: Re: some issues with emacs 25 
Matthew Lear <matt@bubblegen.co.uk> writes:

> On 09/11/16 23:55, David Bremner wrote:
>> I can't find an html only public-message so far to give a full
>> backtrace.
> If it helps, here is some text in *bold *with some changes in red that
> you can test with :-D

FWIW, this doesn't trigger the bug with default settings + (setq
notmuch-mua-compose-in 'new-window) because it has a text part.


[-- Attachment #2: Type: text/html, Size: 1082 bytes --]

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> I can trigger the bug if I discard text/plain though. Did you try that? 
> -------- Original message --------From: David Bremner <david@tethera.net> Date: 11/11/2016  11:40  (GMT+00:00) To: Matthew Lear <matt@bubblegen.co.uk>, Matt Armstrong <marmstrong@google.com> Cc: notmuch@notmuchmail.org Subject: Re: some issues with emacs 25 
> Matthew Lear <matt@bubblegen.co.uk> writes:
>
>> On 09/11/16 23:55, David Bremner wrote:
>>> I can't find an html only public-message so far to give a full
>>> backtrace.
>> If it helps, here is some text in *bold *with some changes in red that
>> you can test with :-D
>
> FWIW, this doesn't trigger the bug with default settings + (setq
> notmuch-mua-compose-in 'new-window) because it has a text part.
>

I'm not sure what you mean by "discard", but closing it isn't enough. I
think more of your settings are needed to replicate the problem with a
multipart/alternative message.

Re: some issues with emacs 25

[Matthew Lear]

On 12/11/16 00:20, David Bremner wrote:
> Matthew Lear <matt@bubblegen.co.uk> writes:
> 
>> I can trigger the bug if I discard text/plain though. Did you try that? 
> 
> I'm not sure what you mean by "discard", but closing it isn't enough. I
> think more of your settings are needed to replicate the problem with a
> multipart/alternative message.
> 

Apologies, David. I wasn't clear at all. I meant that if I discourage
text/plain in a multipart/alternative message, I can trigger the bug.
If I use the following tiny-init.el...

(require 'shr)
(setq mm-text-html-renderer 'shr)
(setq mime-view-text/html-previewer 'shr)
(setq mm-html-inhibit-images nil)
(setq mm-html-blocked-images nil)

(require 'notmuch)
(global-set-key [f1]  'notmuch)
(setq notmuch-mua-compose-in 'new-frame)
(setq notmuch-multipart/alternative-discouraged '("text/plain"))


...and load it using 'emacs-25 -q --load ~/.emacs.d/tiny-init.el',
searching for any mimetype:text/html and replying to it triggers the bug
for me.

Commenting out the setting of notmuch-mua-compose-in is enough to
prevent the problem from occurring.
Cheers,
--  Matt

Re: some issues with emacs 25

[David Bremner]

Matthew Lear <matt@bubblegen.co.uk> writes:

> (setq notmuch-mua-compose-in 'new-frame)
> (setq notmuch-multipart/alternative-discouraged '("text/plain"))


Using devel/try-emacs-mua in the source tree, only these last two lines
are needed. But yes agree, after discouraging text/plain, multipart
messages can also duplicate this bug

> ...and load it using 'emacs-25 -q --load ~/.emacs.d/tiny-init.el',
> searching for any mimetype:text/html and replying to it triggers the bug
> for me.
>
> Commenting out the setting of notmuch-mua-compose-in is enough to
> prevent the problem from occurring.
> Cheers,
> --  Matt