The changelog Atom feed takes commit messages, both single-line ones of arbitrary length from -m and multi-line ones (either multiline in the sense of hard returns at some random character, or multiline in the sense of two newlines for new paragraphs), and stuffs them into a <content type="xhtml"><pre>...</pre></content> wrapper. Because we rarely use either sort of multi-line messages, but we very frequently use single-line ones that are wider than my feed reader's window, reading the changelog feed involves constant horizontal scrolling. There's no simple solution while retaining the ideological purity of a type="xhtml" content element (that would require a much fancier nl2<br/>&<p></p> instead of the simple nl2br/addbreaks filter), but ideological purity doesn't soothe my scrolling finger, and there's very, very little purity in "my inline XHTML is plain text stuffed in a <pre>."
Created attachment 340864 [details] [diff] [review] Fix v.1 The simple fix: convert our plain text with significant whitespace into escaped HTML with newlines turned into breaks. What it lacks in prettiness it more than makes up for in actual readable output.
Well, what would IMHO be better is if people used the convention that there's a relatively short first line describing the fix, then a newline, then some more text describing the changeset, where all of the lines should be < 80 chars.
Comment on attachment 340864 [details] [diff] [review] Fix v.1 Let's talk about how changing the feed output is way easier than changing 10 years of culture around commit messages.
http://hg.mozilla.org/hg_templates/rev/f01159b432aa I scrolled through the 262 mozilla-central entries and 172 comm-central entries my reader has at the moment, and it looks like maybe five people are trying (or tried) to do 80 columns with a first line heading, and of those five one actually managed to do it consistently. Tell you what, how about if we reconsider after you remove -m from hg?