regression(gmail): plain-text drafts still hard-wrap after Gmail web sends them

Summary

The plain-text hard-wrapping reported in #475 still occurs in v0.38.1 for drafts that a human opens and sends from the Gmail web UI.

PR #476 fixed Gog's initial MIME construction: a fresh --body draft now uses quoted-printable encoding, and its decoded raw body remains one logical line. However, after that draft is opened and sent from Gmail web, the sent message contains real CRLF breaks around 70 characters. Gmail's draft editor looks normal before send, so the damage is only visible in the sent message/recipient view.

This appears to be an incomplete fix or integration regression specific to the Gog draft -> Gmail web editor -> send path.

Environment

• Gog: v0.38.1 (324f656a 2026-08-26T04:37:04Z)
• Install: standalone Windows amd64 binary
• OS: Windows 11
• Browser: Chrome / Gmail web
• Draft created through Gmail API by Gog, then sent manually in Gmail web

Steps to reproduce

1. Supply one long paragraph with no \r or \n characters:

   复制

   This is one deliberately long plain-text paragraph supplied to gog without any newline characters. It should remain a single logical line in the MIME body so Gmail can wrap it responsively, but the current draft serializer inserts hard line breaks.

2. Create the draft:

   bash复制

   gog --account [email protected] gmail drafts create \
     --to [email protected] \
     --subject "Plain-text wrapping reproduction" \
     --body "<the single-line paragraph above>" \
     --json --no-input

3. Open the draft in Gmail web. It appears correctly reflowed in the editor.

4. Send it using Gmail web.

5. Fetch the sent message with gog gmail get <messageId> --format=raw --json, base64url-decode the RFC822 message, then quoted-printable-decode the body.

Before-send control

A fresh v0.38.1 draft created with the text above has:

Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: quoted-printable

After base64url and quoted-printable decoding:

INPUT_HAS_NEWLINE False
DECODED_NONEMPTY_LINE_LENGTHS [248]

So #476 is working at initial draft construction time.

Actual result after Gmail web sends the draft

The sent message still has:

Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

But after quoted-printable decoding, the body contains real CRLF paragraph breaks around 70 characters. In the production occurrence that exposed this, representative decoded non-empty line lengths included:

[68, 35, 3, 64, 76, 76, 11, 75, 30, 66, 67, 74, ...]

Those are real post-decode line endings, not quoted-printable soft breaks. The MIME does not include format=flowed, so Gmail and recipients render them as fixed narrow lines.

Expected result

A plain-text paragraph supplied without line endings should remain a reflowing paragraph after a human sends the Gog-created draft from Gmail web, matching how the draft appeared in the editor.

Workaround

Creating the draft with HTML avoids the problem:

gog gmail drafts create \
  --to [email protected] \
  --subject "Subject" \
  --body-html '<p>One continuous paragraph...</p>'

The resulting draft remains text/html and wraps responsively after send.

Possible direction

I am not sure whether Gmail web discards or rewrites the quoted-printable representation when it loads the API-created plain-text draft. Possible fixes may include:

• using an appropriate format=flowed representation for plain-text drafts intended for human editing/sending;
• preserving a reflowable representation that Gmail web will not convert to fixed-width text; or
• documenting that --body / --body-file drafts sent through Gmail web can still hard-wrap, with --body-html as the required workaround.

This is deliberately filed as a regression/incomplete-fix follow-up to #475 and #476 rather than assuming the original quoted-printable fix itself has reverted.