<div dir="ltr">and for the love of god don't send copyrighted ebooks as pdf... </div><div class="gmail_extra"><br><div class="gmail_quote">On 31 October 2015 at 05:38, James R. Haigh <span dir="ltr"><<a href="mailto:james.r.haigh@gmail.com" target="_blank">james.r.haigh@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
I too have some netiquette requests; some overlapping, some partially conflicting but seemingly in a resolvable way. My requests are:<br>
1. ensure compatibility with mail clients that only operate on plaintext (i.e. some TUI and accessibility clients);<br>
2. please don't hard-wrap your emails!;<br>
2.1. if you use Thunderbird then please go to about:config (Preferences → ‘Advanced’ tab → ‘General’ subtab → ‘Config Editor…’) and set ‘mailnews.wraplength’ to <a href="tel:2147483647" target="_blank" value="+12147483647">2147483647</a> (search ‘wrap’ to find it quickly);<br>
2.2. if you know of equivalent solutions in other mail clients then please let me/others know;<br>
3. start your message at the start of your email, or at least very near the start;<br>
4. try not to unnecessarily increase the email's filesize.<br>
<br>
These are not fundamentally incompatible with Ron's requests, and are somewhat overlapping, but there are some conflicting circumstances.<br>
To satisfy point 3 without top-posting (Ron's point 2), one must either reply inline or not quote more than 2 or 3 lines. Both of these resolutions are acceptable and preferable anyway; the former has readability advantages and the latter helps to reduce filesize.<br>
Sending of plain+HTML doesn't conflict with point 1, because a TUI email client that doesn't support HTML can simply use the plaintext part, and discard the HTML part if desired. Also, there exist TUI Web browsers (W3m, Lynx, Links, etc.) so it doesn't seem like HTML is fundamentally incompatible with TUI email clients, though, granted, it may not be implemented in someone's preferred client.<br>
Sending of plain+HTML doesn't conflict with point 4 if this is considered a necessity. I consider the avoidance of hard-wrapping to be a necessity. However, there's no /fundamental/ reason why clients cannot address the plaintext hard-wrapping problem.<br>
<br>
---- Avoidance of hard-wrapping of plaintext ----<br>
Mail clients often can't easily be told to not hard-wrap when sending plaintext email, even though HTML email doesn't suffer from this issue. This used to be a reason for me to prefer plain+HTML emails as a best-of-both (except not best filesize). However, I've relatively recently found a way to disable hard-wrapping for the plaintext too in Thunderbird by setting ‘mailnews.wraplength’ to a number that would never cause hard-wrapping. That might as well be the 32-bit integer limit of <a href="tel:2147483647" target="_blank" value="+12147483647">2147483647</a>. When displayed, the email client soft-wraps the email at the currently available width, allowing windows to be resized arbitrarily and achieve preferred width for optimal readability or other reasons.<br>
_Please note that I use a tiling window manager (XMonad), so being able to resize windows arbitrarily without breakage is as important as it is to not cause breakage for someone who prefers TUI mail clients._<br>
I've never used a TUI mail client but even if I did I'd still find it important to have emails display at the with of /my/ terminal rather than the width of terminals of circa the 199th decade. Neither my virtual terminals (the TTYs accessible with (Ctrl+)Alt+F{1..6} by default on most distros) or my terminal emulator (Gnome Terminal) is set to a font size that gives about 80 characters width at the screen width, nor do I want it to be. ‘stty size’ reports that my virtual terminals are currently 48 rows, 128 columns and Gnome Terminal filling the XMonad+Taffybar workspace is 56 rows, 145 columns. Worse still, when tiled vertically at half-width, the Gnome Terminals are 72 columns, just below the legacy 80 character convention, and this breaks terribly in that each line wraps its last word or 2 onto the next line. Hard-wrapping causes serious readability problems, and due to such an operation losing semantic information (the difference between true newlines and hard-wrap breakpoints), hard-wrapping can not unambiguously be corrected by software.<br>
When inline-replying to individual sentences of a plaintext paragraph, remember to make sure that all parts of the paragraph that are now on their own line are proceeded with the correct number of greater than symbols (‘>’), one for each nested quote-level.<br>
<br>
---- Unnecessary quoting ----<br>
Inline-replying is generally the most readable way to reply but sometimes the points in the existing message don't directly correlate with how one wants to reply (as in this case) making it difficult to write in a way that flows in such cases. Top or bottom -posting can have serious problems for the reader. Nevertheless, when /nothing/ is quoted then there's no distinction between top, inline, and bottom -posting.<br>
Seeing as the only reason for quoting an entire email when not replying inline is incase a recipient hasn't got a copy of the previous email, it seems much more appropriate to instead link to the publicly archived message rather than to duplicate the entire message for all existing mailing list members. That would replace lengthy, unnecessary quotes, greatly reducing filesize and clutter, as exemplified after my signature of this message. It also avoids the issue of broken flow of top-posting – the order of the flow is the order of chronological sorting in your mail client (or archive list), newest at the bottom being the recommended order.<br>
However, this begs a way to automate it otherwise it would be tedious and inconsistent. Perhaps this should be implemented in GNU Mailman such that each footer that it applies to an email contains the archive URL of that email, then it's just a matter of deleting all of the quoted text except for this URL. This may not be trivial to implement though because it would require synchronous integration with Pipermail – the archive URL must be allocated before the email is sent and archived. Every email in the archives would contain a self-referencing URL in the footer. That has its advantages if it could be implemented, but I'm not sure how hard that would be.<br>
<br>
Can we find common ground on these issues?<br>
<br>
Best regards,<br>
James.<br>
--<br>
Sent from Thunderbird on NixOS!<br>
At 2015-10-29Thu10:14, Ron Wellsted wrote the message that is archived at:<br>
<a href="https://mailman.lug.org.uk/pipermail/wolves/2015-October/031509.html" target="_blank" rel="noreferrer">https://mailman.lug.org.uk/pipermail/wolves/2015-October/031509.html</a><br>
<br>
<br>
_______________________________________________<br>
Wolves LUG mailing list<br>
Homepage: <a href="http://www.wolveslug.org.uk/" target="_blank" rel="noreferrer">http://www.wolveslug.org.uk/</a><br>
Mailing list: <a href="mailto:Wolves@mailman.lug.org.uk" target="_blank">Wolves@mailman.lug.org.uk</a><br>
Mailing list home: <a href="https://mailman.lug.org.uk/mailman/listinfo/wolves" target="_blank" rel="noreferrer">https://mailman.lug.org.uk/mailman/listinfo/wolves</a></blockquote></div><br></div>