Better tools for kernel developers

Posted Feb 10, 2020 8:42 UTC (Mon) by geert (subscriber, #98403)
In reply to: Better tools for kernel developers by DSMan195276
Parent article: Better tools for kernel developers

I have used the GMail web interface for almost all of my interaction with Linux mailing lists since 2009, except for:
1. Sending patches (git send-email using the SMTP server of my ISP),
2. Replying to patches on mailing lists I'm not subscribed to, and thus downloaded from lore or patchwork (alpine is still in my fingers).

Yes, GMail has lost the ability to not corrupt patches copy-'n-pasted to the web interface many years ago :-(

Better tools for kernel developers

Posted Dec 23, 2020 16:23 UTC (Wed) by tbelaire (subscriber, #141140) [Link] (5 responses)

What exactly does Gmail break? Is it just line wrapping or is it anything else?

I do work on Gmail, if there's a clear test case maybe I could try and fix this. Though I'm a little afraid of touching that part of the code base as there are a lot of tools which parse emails, and I wouldn't know if my change broke something until too late.

I suppose more usefully, how would I test this? I could generate a patch with git, copy it into gmail (after the fix), send it to myself and copy the body from gmail web into a .patch file, which I feed to git?
Or would I need to set up mutt or something in order to get the email in a form git likes? I haven't sent patches by email successfully before.

Can you include the patch file as an attachment instead?

Better tools for kernel developers

Posted Dec 24, 2020 0:34 UTC (Thu) by foom (subscriber, #14868) [Link] (3 responses)

Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

Other popular mailers have stopped doing hardwrapping years ago, and now simply send long lines as long lines, without inserting any extraneous linebreaks. In order to remain compliant with SMTP standards, which prohibits long lines, you must encode the message as quoted-printable if the lines are too long. But, quoted-printable encoding is reversible and transparent to the content, unlike inserting hard linebreaks.

A previous solution to the mobile problem was to use text/plain;format=flowed, but that format=flowed was a complex spec that had many problems of its own, and never interoperated well. It's fallen out of favor in recent decades (yes, decades!!!), in favor of simply never hard-wrapping text/plain content.

Better tools for kernel developers

Posted Dec 26, 2020 2:25 UTC (Sat) by zlynx (guest, #2285) [Link] (2 responses)

> Gmail hard-wraps plaintext mails at 78 columns. It should stop doing so. Fixing this in gmail would also make its plaintext emails more readable on mobile devices.

It's vague in my memory, but I am almost certain that wrapping around 72 and definitely before 80 is *required* for email user agents.

Yes, yes, it is commonly ignored for pasted or included content, but any email program that you type into is supposed to wrap long line at some point before 80, leaving room for at least three levels of quotes, like "> > > " which is six. So at least 74, more likely 72. 78 is being overly generous really.

This kind of sounds like someone complaining about Google's GMail *following standards*. Weird.

Better tools for kernel developers

Posted Dec 26, 2020 5:02 UTC (Sat) by mjg59 (subscriber, #23239) [Link]

There's no hard requirement that user agents wrap text - it's convention to do so for the purposes of quoting stuff on 80 characters wide terminals, but doing so is inherently lossy when using plain ASCII (there's no way to tell the difference between a 72-character line followed by an 8-character line and an 80-character line that got hard wrapped). RFC5322 does say that agents SHOULD place a 78-character restriction on line length, but the context provided makes it pretty clear that it's talking about written language rather than code.

Better tools for kernel developers

Posted Dec 27, 2020 4:23 UTC (Sun) by foom (subscriber, #14868) [Link]

Sure, that was a common convention in the past, but many other user agents have stopped hard-wrapping years ago, because at this point it does more harm than good.

Better tools for kernel developers

Posted Dec 24, 2020 14:51 UTC (Thu) by geert (subscriber, #98403) [Link]

Using attachments is not an option, as it makes it hard to comment on attached patches.

Test procedure:

1. Generate patch with "git format-patch -1",
2. Revert top change using "git reset --hard HEAD^",
2. Open patch with e.g. gedit,
3. Paste patch into email body using gmail web interface,
4. Send email,
5. Open received email,
6. Select "Download message" from triple-dot menu,
7. Apply patch using "git am" (should apply cleanly),
8. Use "git diff" to check tree contents (should match state with step 1).

The above used to work, until Gmail started replacing TABs in pasted patches by spaces several years ago.
More things may have been broken afterwards (e.g. forced line break).

Thanks a lot!