Fill mismatch between message mode and org mode

[morganwillcock]

Hello,

It seems that having Org mode configured to use a different fill width breaks the text wrapping in sent messages. I happened to have the following hooks configured:

(add-hook 'org-mode-hook '(lambda () (setq fill-column 80)))
(add-hook 'org-mode-hook 'turn-on-auto-fill)

When sending the following text (which org-msg-mode is wrapping at 80 characters):

Lorem Ipsum is simply dummy text of the printing and typesetting industry. Lorem
Ipsum has been the industry's standard dummy text ever since the 1500s, when an
unknown printer took a galley of type and scrambled it to make a type specimen
book. It has survived not only five centuries, but also the leap into electronic
typesetting, remaining essentially unchanged. It was popularised in the 1960s
with the release of Letraset sheets containing Lorem Ipsum passages, and more
recently with desktop publishing software like Aldus PageMaker including
versions of Lorem Ipsum.

...the message parts looks like this, where the text part is badly filled but the HTML version still renders without an obvious problem (although the source looks strange):

Lorem Ipsum is simply dummy text of the printing and typesetting
industry. Lorem
Ipsum has been the industry's standard dummy text ever since the 1500s,
when an
unknown printer took a galley of type and scrambled it to make a type
specimen
book. It has survived not only five centuries, but also the leap into
electronic
typesetting, remaining essentially unchanged. It was popularised in the
1960s
with the release of Letraset sheets containing Lorem Ipsum passages, and
more
recently with desktop publishing software like Aldus PageMaker including
versions of Lorem Ipsum.

<p style=3D"text-decoration:none;margin-bottom:0px;margin-top:10px;line-hei=
ght:11pt;font-size:10pt;font-family:&quot;Arial&quot;;">
Lorem Ipsum is simply dummy text of the printing and typesetting industry. =
Lorem<br/>
Ipsum has been the industry's standard dummy text ever since the 1500s, whe=
n an<br/>
unknown printer took a galley of type and scrambled it to make a type speci=
men<br/>
book. It has survived not only five centuries, but also the leap into elect=
ronic<br/>
typesetting, remaining essentially unchanged. It was popularised in the 196=
0s<br/>
with the release of Letraset sheets containing Lorem Ipsum passages, and mo=
re<br/>
recently with desktop publishing software like Aldus PageMaker including<br=
/>
versions of Lorem Ipsum.<br/></p>

Personally I don't have too many issues with just going back to filling at 72 characters for Org mode to fix the problem, but I thought I should report it in-case there is a graceful way that Org-Msg could have a custom value for its fill width which can override anything defined for Org mode - perhaps it would be possible to query the value used in message mode and use this instead to avoid a mismatch.

Thanks, Morgan

[jeremy-compostella]

I think I have addressed this already in the experimental branch. See 5e471b6.

[morganwillcock]

Thanks. It does fix the issue with the plain text part. The width of the HTML part is a little more problematic than I first thought as a quoted long line being wrapped in the Gnus article viewer can be wrapped in a way that breaks the quoting.

So when sending this:

> Lorem Ipsum is simply dummy text of the printing and typesetting
> industry. Lorem Ipsum has been the industry's standard dummy text ever since
> the 1500s, when an

...the HTML part of the received message is displayed in the article viewer (rendered through shr) as:

> Lorem Ipsum is simply dummy text of the printing and typesetting
> industry. Lorem Ipsum has been the industry's standard dummy text
ever since
> the 1500s, when an

...which breaks quoting on a traditional (non Org-Msg) reply:

>> Lorem Ipsum is simply dummy text of the printing and typesetting
>> industry. Lorem Ipsum has been the industry's standard dummy text
> ever since
>> the 1500s, when an

...but I cannot see that any of that is down to the HTML produced by Org-Msg being wrong, as where the article viewer is wrapping the lines doesn't align with the \
tag in the HTML or the literal line breaks.

I'm happy to close this issue if the changes on the experimental branch are going to be merged.

[jeremy-compostella]

This other issue is indeed caused by the render engine and there is nothing org-msg can do about it. I was expecting that setting shr-width to -1 would resolve this but it turns out that this value is enforced to nil by mm-shr before the call to shr-insert-document. To me it looks like a bug but on the other side the -1 value of shr-width seems to be an undocumented trick. If I were you I would place an :around advice on the shr-insert-document function which would set the shr-width variable to -1. This should resolve your issue.

I'm happy to close this issue if the changes on the experimental branch are going to be merged.

What is on the experimental branch usually end-up in the master branch sooner or later. This is where I put my work in progress patches while I or other people test them.

[morganwillcock]

This other issue is indeed caused by the render engine and there is nothing org-msg can do about it. I was expecting that setting shr-width to -1 would resolve this but it turns out that this value is enforced to nil by mm-shr before the call to shr-insert-document. To me it looks like a bug but on the other side the -1 value of shr-width seems to be an undocumented trick. If I were you I would place an :around advice on the shr-insert-document function which would set the shr-width variable to -1. This should resolve your issue.

Thanks for having a look. I did eventually track down the fill being optionally applied, to the value of shr-use-fonts. It seems that setting this to nil (to use monospaced fonts) forces a fill, and setting it to t (to use proportional fonts) skips the fill.

[jeremy-compostella]

Indeed, but I did not find that to be a very satisfying option.