Today, I have sent an HTML e-mail to a sr.ht mailing list (HTML by
accident).
The answer e-mail pointing me to https://useplaintext.email looks badly
formatted on my smartphone because it (ironically) uses hard
line-breaks. Not `format=flowed` as recommended. Screenshot:
https://0x0.st/XoMe.png
It would be nice using `format=flowed` for these e-mails.
Дана 24/04/18 08:21PM, Max Schillinger написа:
> Today, I have sent an HTML e-mail to a sr.ht mailing list (HTML by > accident).> > The answer e-mail pointing me to https://useplaintext.email looks badly > formatted on my smartphone because it (ironically) uses hard > line-breaks. Not `format=flowed` as recommended. Screenshot:> > https://0x0.st/XoMe.png> > It would be nice using `format=flowed` for these e-mails.
In that webpage, format=flowed is described as "optional". The preferred method
should be to wrap the text (personally, I use 80 columns instead of 72,
although I can see why 72 might be preferred (TUI mail clients having
"scrollbars", numbered lines, "dividers", etc).
> In that webpage, format=flowed is described as "optional".
OK, you are right. It's optional but nevertheless it's useful because my
smartphone doesn't show more than 52 characters per line. I guess most
smartphones are below 72 characters.
This could be the patch to enable `format=flowed`:
https://lists.sr.ht/~sircmpwn/public-inbox/patches/51118
But it's not tested because I don't know how. To run this script, I have
to install the repository's python package. But this requires another
package (core.sr.ht/srht). And that complains about a wrong setuptools
version. Welcome to dependency hell :-)
On Thu Apr 18, 2024 at 8:21 PM CEST, Max Schillinger wrote:
> It would be nice using `format=flowed` for these e-mails.
Aside from comments I send to the suggested patch, I have also
https://www.fastmail.com/blog/format-flowed/ … I am afraid this
idea is just dead and mouldy, especially for the system which is
based mostly around git send-email.
Best,
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
In political activity men sail a boundless and bottomless sea;
there is neither harbor for shelter nor floor for anchorage,
neither starting point nor appointed destination.
-- Michael Oakeshott: Rationalism in Politics
My current impression is that the only solution that doesn't make text look unpleasant, e.g. as in the original message's screenshot, is to send messages without hard wrapping, and to expect and/or change clients to have them wrap text at one's preferred column size.
lists.sr.ht, for example, does not break lines. I think it's non-trivial to do so, for example because for patches, lines in the body should be broken, but lines in the patch itself should not. Maybe this could be solved in some way so that long lines are shown nicely in the web UI.
Happy to hear what people think about this and if there are things I've overlooked.
Indeed, the original reason for either hard wrapping or format=flowed (the 998 character limit of SMTP) is no longer relevant given `Content-Transfer-Encoding: quoted-printable`. I really don't see much reason to do anything other than "no wrap"+quoted-printable for general mail nowadays.
See also https://incenp.org/notes/2022/no-format-flowed.html
- Ellie
On Fri Apr 19, 2024 at 7:14 PM CEST, Eleanor Clifford wrote:
> Indeed, the original reason for either hard wrapping or format=flowed (the 998 character limit of SMTP) is no longer relevant given `Content-Transfer-Encoding: quoted-printable`. I really don't see much reason to do anything other than "no wrap"+quoted-printable for general mail nowadays.>> See also https://incenp.org/notes/2022/no-format-flowed.html
Also:
# Don’t send patches with format=flowed. This can cause unexpected and unwanted line breaks.
(from
https://www.kernel.org/doc/html/latest/process/email-clients.html
… if hard-core geeks like that don’t want that, who does? For
everybody else, as the ad says, is Mastercard and HTML)
Matěj
--
http://matej.ceplovi.cz/blog/, @mcepl@floss.social
GPG Finger: 3C76 A027 CA45 AD70 98B5 BC1D 7920 5802 880B C9D8
Ludwig Boltzmann, who spent much of his life studying statistical
mechanics, died in 1906, by his own hand. Paul Ehrenfest,
carrying on the work, died similarly in 1933. Now it is our turn
to study statistical mechanics.
-- David L. Goodstein “States of Matter”
On Fri, Apr 19, 2024, at 1:14 PM, Eleanor Clifford wrote:
> Indeed, the original reason for either hard wrapping or format=flowed > (the 998 character limit of SMTP) is no longer relevant given > `Content-Transfer-Encoding: quoted-printable`. I really don't see much > reason to do anything other than "no wrap"+quoted-printable for general > mail nowadays.
Hard wrapping is still desirable because very often nowadays the
window in which one is reading some text is much, much wider than
the ideal width of the text itself, which, for basic physiological
reasons, should never be more than about 100 columns.
zw
On Fri, Apr 19, 2024 at 01:52:26PM -0400, Zack Weinberg wrote:
> Hard wrapping is still desirable because very often nowadays the window in which one is reading some text is much, much wider than the ideal width of the text itself, which, for basic physiological reasons, should never be more than about 100 columns.
IMO that's a problem on the client end and shouldn't influence how mail is actually encoded -- configure your MUA to wrap text with fewer columns, or just make your window less wide.
Semantics and style should not be conflated -- this is a basic principle of accessibility.
- Ellie
Sourcehut extends the traditions of Unix hackers, which is a welcome breath of
fresh air in today's time of Github and mainstream development practices.
That's really the whole appeal of Sourcehut - the "Hacker's Forge".
Mobile phones with HTML email, repository management through web interface
loaded with bloated JavaScript frameworks, WASM, Google Analytics and code
funneling to AI should not be first-class citizens, 80x25 text terminals and
git send-email should.
Дана 24/04/19 07:41PM, Eleanor Clifford написа:
> IMO that's a problem on the client end and shouldn't influence how mail is > actually encoded -- configure your MUA to wrap text with fewer columns, or just > make your window less wide.
One could turn this around and say: fix mobile "apps" to show emails correctly,
or just use the right tools for the job instead - PCs.
On Fri, Apr 19, 2024, at 2:41 PM, Eleanor Clifford wrote:
> On Fri, Apr 19, 2024 at 01:52:26PM -0400, Zack Weinberg wrote:>> Hard wrapping is still desirable because very often nowadays the window in which one is reading some text is much, much wider than the ideal width of the text itself, which, for basic physiological reasons, should never be more than about 100 columns.>> IMO that's a problem on the client end and shouldn't influence how mail > is actually encoded -- configure your MUA to wrap text with fewer > columns, or just make your window less wide.
HTML-based mailing list archives generally give me no option here. Resizing
the whole window may mangle the rest of the UI. (If someone would like to
write a Firefox extension that gives me the ability to forcibly resize
*specific CSS boxes*, and persist that across visits as a user style sheet
or something, please do!)
zw
On Fri, Apr 19, 2024 at 09:12:03PM +0200, Страхиња Радић wrote:
> Mobile phones with HTML email, repository management through web interface loaded with bloated JavaScript frameworks, WASM, Google Analytics and code funneling to AI should not be first-class citizens, 80x25 text terminals and git send-email should.
Bloat is bad, I agree. Being unable to use a phone at all is not. There are plenty of phone clients that are nothing like this, they shouldn't be second class citiens.
> One could turn this around and say: fix mobile "apps" to show emails correctly, or just use the right tools for the job instead - PCs.
Re-flowing hard-wrapped text is undecidable in general. Wrapping unwrapped text is easy.
Using unwrapped text pretty much doesn't impact users of 80x25 text terminals at all.
- Ellie.
Zack Weinberg wrote:
> (If someone would like to write a Firefox extension that gives me the ability to forcibly resize *specific CSS boxes*, and persist that across visits as a user style sheet or something, please do!)
If I understand correctly, you should be able to do this with userContent.css
- Ellie
On Fri, Apr 19, 2024, at 3:22 PM, Eleanor Clifford wrote:
> Zack Weinberg wrote:>> (If someone would like to write a Firefox extension that gives me the>> ability to forcibly resize *specific CSS boxes*, and persist that>> across visits as a user style sheet or something, please do!)>> If I understand correctly, you should be able to do this with> userContent.css
Yes, what I want out of an extension is a nice direct manipulation
interface (similar to uBlock Origin's pick-a-CSS-box-to-hide interface)
that writes to userContent.css. I do sometimes do this by hand using
the page debugger but that's more awkward than a single-purpose
extension would be, and it doesn't persist.
zw
On Fri Apr 19, 2024 at 3:24 PM CEST, Matěj Cepl wrote:
> Aside from comments I send to the suggested patch, I have also> https://www.fastmail.com/blog/format-flowed/ … I am afraid this> idea is just dead and mouldy, especially for the system which is> based mostly around git send-email.
It's sad that this standard is not widely adopted. But using it whenever
you can, never harms. I understand that format=flowed might damage a
patch (AFAIU only when "soft line breaks" are added automatically
everywhere). Actually, I have disabled format=flowed in aerc because of
this. On the other hand, aerc is not involved when I send patches. Maybe
I just need to configure vim correctly.
On Fri Apr 19, 2024 at 5:36 PM CEST, Vlad-Stefan Harbuz wrote:
> My current impression is that the only solution that doesn't make text look unpleasant, e.g. as in the original message's screenshot, is to send messages without hard wrapping, and to expect and/or change clients to have them wrap text at one's preferred column size.>> lists.sr.ht, for example, does not break lines. I think it's non-trivial to do so, for example because for patches, lines in the body should be broken, but lines in the patch itself should not. Maybe this could be solved in some way so that long lines are shown nicely in the web UI.
Indeed, your e-mails look good on my smartphone (in K-9 Mail). But they
look not so good on my laptop (in aerc) and bad on lists.sr.ht.
For the software I currently use, this would be my ranking:
1. format=flowed looks good in K-9 Mail, aerc and on lists.sr.ht.
2. hard-wraps look bad in K-9 Mail, good in aerc and good on
lists.sr.ht.
3. long, unwrapped lines look good in K-9 Mail, okay in aerc (can
probably be configured) and bad on lists.sr.ht because I have to scroll
horizontally (wide screen, no smartphone).
But if lists.sr.ht would wrap lines at the right border of the text box,
it would look different. :-)
On Fri 19 Apr 2024 22:21:27, Max Schillinger wrote:
> But they look not so good on my laptop (in aerc)
:pipe fmt -su
makes them look better :)
--
Moritz Poldrack
https://moritz.sh> Do not open shrink-wrap until you have read and agreed to the conditions> contained within.
On Fri Apr 19, 2024 at 10:29 PM CEST, Moritz Poldrack wrote:
> :pipe fmt -su>> makes them look better :)
Thank you!
This seems to work as default as well:
[viewer]
pager=sh -c 'fmt -su | less -Rc'
On 2024-04-19 21:29, Zack Weinberg wrote:
> Yes, what I want out of an extension is a nice direct manipulation> interface (similar to uBlock Origin's pick-a-CSS-box-to-hide interface)> that writes to userContent.css. I do sometimes do this by hand using> the page debugger but that's more awkward than a single-purpose> extension would be, and it doesn't persist.> > zw
Have you considered Stylus? It admittedly does not have a "direct
manipulation interface", but if you are already familiar with the
page debugger it might be what you are looking for.
However, if you have not yet considered it, be warned, since it goes
usually like this:
1. Install Stylus (if still needed).
2. On a sr.ht page select "Write new style as UserCSS" for "sr.ht"
3. Start with a first rule
.message-body { white-space: pre-wrap; }
and press the save button, which immediately shows effect on the
styled pages: Long lines in messages on sr.ht wrap nicely.
4. Then you decide that 80 character width would be even more
readable, so you extend:
.message-body {
white-space: pre-wrap;
max-width: 80ch;
}
5. But then the rest of the page looks awkward, so you start drawing
element trees and read on MDN about flex boxes and grid boxes and
whatnot.
6. You remember about userstyles.org (mostly down) and
userstyles.world (does not have yet anything reasonable for
sr.ht) so you continue with 5.
Another evening wasted, but you have learned something about CSS.
On 2024-04-30 22:42, Jens Schmidt wrote:
> Another evening wasted, but you have learned something about CSS.
Actually I found the following by more tweaking:
div.container {
width: fit-content;
}
.message-body {
white-space: pre-wrap;
max-width: 80ch;
}
so it was not a whole evening this time.