[Wolves] Netiquette
Adam Sweet
adamsweet at gmail.com
Mon Nov 2 17:37:47 UTC 2015
On 31/10/15 14:34, Suntish T. Narain wrote:
> and for the love of god don't send copyrighted ebooks as pdf...
Hey man, glad you're still out there :)
Ad
> On 31 October 2015 at 05:38, James R. Haigh <james.r.haigh at gmail.com
> <mailto:james.r.haigh at gmail.com>> wrote:
>
> Hello,
> I too have some netiquette requests; some overlapping, some
> partially conflicting but seemingly in a resolvable way. My requests
> are:
> 1. ensure compatibility with mail clients that only operate on
> plaintext (i.e. some TUI and accessibility clients);
> 2. please don't hard-wrap your emails!;
> 2.1. if you use Thunderbird then please go to about:config
> (Preferences → ‘Advanced’ tab → ‘General’ subtab → ‘Config Editor…’)
> and set ‘mailnews.wraplength’ to 2147483647 <tel:2147483647> (search
> ‘wrap’ to find it quickly);
> 2.2. if you know of equivalent solutions in other mail clients
> then please let me/others know;
> 3. start your message at the start of your email, or at least very
> near the start;
> 4. try not to unnecessarily increase the email's filesize.
>
> These are not fundamentally incompatible with Ron's requests,
> and are somewhat overlapping, but there are some conflicting
> circumstances.
> 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.
> 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.
> 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.
>
> ---- Avoidance of hard-wrapping of plaintext ----
> 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 2147483647 <tel:2147483647>. 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.
> _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._
> 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.
> 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.
>
> ---- Unnecessary quoting ----
> 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.
> 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.
> 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.
>
> Can we find common ground on these issues?
>
> Best regards,
> James.
> --
> Sent from Thunderbird on NixOS!
> At 2015-10-29Thu10:14, Ron Wellsted wrote the message that is
> archived at:
> https://mailman.lug.org.uk/pipermail/wolves/2015-October/031509.html
>
>
> _______________________________________________
> Wolves LUG mailing list
> Homepage: http://www.wolveslug.org.uk/
> Mailing list: Wolves at mailman.lug.org.uk
> <mailto:Wolves at mailman.lug.org.uk>
> Mailing list home: https://mailman.lug.org.uk/mailman/listinfo/wolves
>
>
>
>
> _______________________________________________
> Wolves LUG mailing list
> Homepage: http://www.wolveslug.org.uk/
> Mailing list: Wolves at mailman.lug.org.uk
> Mailing list home: https://mailman.lug.org.uk/mailman/listinfo/wolves
>
More information about the Wolves
mailing list