Closed morganwillcock closed 3 years ago
I think I have addressed this already in the experimental branch. See 5e471b6.
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.
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.
This other issue is indeed caused by the render engine and there is nothing
org-msg
can do about it. I was expecting that settingshr-width
to -1 would resolve this but it turns out that this value is enforced tonil
bymm-shr
before the call toshr-insert-document
. To me it looks like a bug but on the other side the-1
value ofshr-width
seems to be an undocumented trick. If I were you I would place an:around
advice on theshr-insert-document
function which would set theshr-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.
Indeed, but I did not find that to be a very satisfying option.
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:
When sending the following text (which org-msg-mode is wrapping at 80 characters):
...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):
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