From owner-freebsd-questions@freebsd.org Tue Jun 16 14:47:56 2020 Return-Path: Delivered-To: freebsd-questions@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 008ED33C2F1 for ; Tue, 16 Jun 2020 14:47:56 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from mout.kundenserver.de (mout.kundenserver.de [217.72.192.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.kundenserver.de", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49mWJp75ZBz46GF for ; Tue, 16 Jun 2020 14:47:54 +0000 (UTC) (envelope-from freebsd@edvax.de) Received: from r56.edvax.de ([178.8.33.9]) by mrelayeu.kundenserver.de (mreue107 [212.227.15.183]) with ESMTPA (Nemesis) id 1M4rD7-1jn8Hg1fE7-001w9N; Tue, 16 Jun 2020 16:47:51 +0200 Date: Tue, 16 Jun 2020 16:47:51 +0200 From: Polytropon To: Chris Knipe Cc: Aryeh Friedman , "Steve O'Hara-Smith" , Polytropon , FreeBSD - Subject: Re: Mailing List Etiquette was freebsd vs. netbsd Message-Id: <20200616164751.dbc4888a.freebsd@edvax.de> In-Reply-To: References: <20200613154409.GA89618@neutralgood.org> <13115.1592302784@segfault.tristatelogic.com> <20200616071153.00006f4d@seibercom.net> <20200616075548.000066f1@seibercom.net> <20200616140416.bd7b8bf2.freebsd@edvax.de> <20200616142043.7d599458.freebsd@edvax.de> <20200616144141.6203d978e9bd43418b17dcbc@sohara.org> Reply-To: Polytropon Organization: EDVAX X-Mailer: Sylpheed 3.1.1 (GTK+ 2.24.5; i386-portbld-freebsd8.2) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:h0oyFuveBDK1vX6UR1cM6jzHu+yCnMR3smuGhzqe2l86V+9aK0M I2UmG1YbbkLsgE2mG7XGXwwz+Mb4N0upC/vF0SvcznvxlpmeFaUbwJP1k/+RkcDZmCHEXVZ iEmsuArK1BVwvoSO/Ndm3SroFYxuHhPp/Cvm56vXEmN2sYOvEZqY8+C5KBE+OzYcBcJ//oR rFsD9woCkTBVBY7lsxXkQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:qm38dLujbZs=:9YNbx6HK0ZRBTY8pUDVk1w /SrwpaExsyOj0iFpmQhDAZPH4mR+PEs/yPwnkwUEcq7cpcbGWJQhPUV6ot0tTAfUiHnVTNcyF gmcRF6aNNABZiYaS8gB1IA5XiRWPiivoX+X2XVYDUZuQp10sjgDvAa2CcnNFc7KKuAwDgJdQF krO1c8iG8Z2g9VETIackCXwWQaO2ihk7CJUYrmPaUQLu1M5z3lKyexdK3IjXV43aYvvF6WEo/ ww+3l+juQ7Qolx2GOdu0pyl+6o9Z8+Ef63G72e1mpi6iTe5GzjhKvhGbPGlqgH3zNAFD5jXlj agEcbG8/xGXeaEyjVIOStFrSWDAfOWK6XoDsF+LzTz2vr+DqAZdqnXWQP5B+ma83vdL1EN3+x DPQzJatOgdZAUuk2XUqlOq973Ge0kglhIE4LvHyQd5Ro09tPaBEXN3zJsIjuyif+oiPIPocED kyOv5TLy3NyHPgpQOKlKlH4BPNFmt6sYJAmE3AQMUnW/yuRQHJc3ZBLolUlNCxjcomtnarJoI TPOyaEvyivjQ0Qx4riZnNylphLeDs15i/MIJD0GtPhyU1/bPa7AvvWYp2GNYcsXMSYGiS6qYA ngXhm9Fw5E80q7FG9j9eW4vMcH2mEVjCy+L3uorTvaCRTaOriERBiZr4ond9+6etbE+v2OZl9 YuLTpH4pj5MILjkG7egGnv2Qq82z2sknO1r6P1I35XqYUuL2NlrPWz+X0QFIUQYsIoU+ZVMh5 km459gV9XRzHfxDClh31mrhHDLSb0qEpP6i4sAkvHsJLgulKhIbveKx8gVLnL6NS9dEBwFY+k qtzeoxVgdaKKGqqdblyE2IFltfWgfYXvTqc4krn7yRK3o0PFEOJu+Wg37Lhlrq3q1ejraT/ X-Rspamd-Queue-Id: 49mWJp75ZBz46GF X-Spamd-Bar: ++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@edvax.de has no SPF policy when checking 217.72.192.74) smtp.mailfrom=freebsd@edvax.de X-Spamd-Result: default: False [4.32 / 15.00]; HAS_REPLYTO(0.00)[freebsd@edvax.de]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; RCPT_COUNT_FIVE(0.00)[5]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.57)[-0.571]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; R_DKIM_NA(0.00)[]; ASN(0.00)[asn:8560, ipnet:217.72.192.0/20, country:DE]; MIME_TRACE(0.00)[0:+]; RECEIVED_SPAMHAUS_PBL(0.00)[178.8.33.9:received]; ARC_NA(0.00)[]; REPLYTO_EQ_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TAGGED_RCPT(0.00)[]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[edvax.de]; AUTH_NA(1.00)[]; NEURAL_SPAM_MEDIUM(0.17)[0.171]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.82)[0.821]; MID_CONTAINS_FROM(1.00)[]; RCVD_IN_DNSWL_NONE(0.00)[217.72.192.74:from]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[217.72.192.74:from]; FREEMAIL_CC(0.00)[gmail.com,sohara.org,edvax.de,freebsd.org]; RCVD_COUNT_TWO(0.00)[2]; SUSPICIOUS_RECIPS(1.50)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Jun 2020 14:47:56 -0000 On Tue, 16 Jun 2020 16:04:21 +0200, Chris Knipe wrote: > On Tue, Jun 16, 2020 at 4:01 PM Aryeh Friedman > wrote: > > > > > > > On Tue, Jun 16, 2020 at 9:54 AM Chris Knipe wrote: > > > >> > >> Why can't your MUA be intelligent enough to wrap emails with > 74 > >> characters on a line? > >> > > > > Because programs that try to be "smart" about things are often "too smart > > for their own good". For example what is to stop it from wrapping > > something that for various reasons *HAS* to be longer than 74 chars (like > > code) when such wrapping destroys the ability to cut and paste from the MUA > > into another file for testing? > > > > Here goes a good example: > > > > > Simple - don't email it. Why not? > If you do, attach it as an attachment (MIME is > there for a reason)... > > There's GIT / CVS / Take your pick for a reason... :-) Those are external resources that can vanish for some reason. The goal of the mailing list is that messages can be processed off-line, and they are perfectly allowed (!) to contain things like source code, ASCII tables, even simple networking diagrams or even formulas. Incornporating "external technology" for something the medium can do in its own doesn't sound very convenient (even though it sounds "modern", so it could probably appeal to certain users just due to this fact). Some mailing lists, such as this one, do not use binary attachments. Using text attachments for code is probably possible. However, this is a _discussion_ mailing list, not primarily intended for sharing code. That doesn't stop users from presenting code in the context of questions (and when I say code, I also mean scripts, logs, sometimes ASCII diagrams, or configuration files). In an earlier message I presented an example for a MUA/MTA construct that was "too smart" - in fact: stupid, which therefore collapsed everything into one single line, and it doesn't matter if another MUA displays that single line as one line, requiring you to scroll, or rensers it as a paragraph (ragged right or justified). The result was an unusable message. I also presented the workaround the users became friends with. :-) Visual presentation of data is a different "layer" than the data itself. And there is no 1:1 relation. Things like font size and displaying should not be a matter of the mail message itself, except... yes, it's not that easy! As a programmer, you will surely agree that there is: a) text that should be presented as it was written, b) text that the MUA is free to (and should) arrange, and c) text where it simply doesn't matter what the MUA does. Making this choice isn't always easy. Multipart-MIME can be helpful. Even though a mailing list is, by no means, a "one size fits all" solution, so there is a certain consensus about what is useful and what is rather not. This consensus changes over time, and within this consensus, there are many ways a user can express his questions, answers, suggestions and thoughts in a mailing list message. Physical things like display size can have significant influence, as well as the kind of device in use, and the way that device is configured. Screens have lots of parameters: { physical size in cm, physical size in px, giving resolution / density } x { software graphics resolution, font face, font size, magnification applied }. It's just not easy to predict - from _your_ point of view -, how a message will be displayed to someone else. You can hope their setting matches what works for you, but you cannot expect that. Coming from a multi-OS background, interoperability, compatibility and "must work everywhere" is something that I consider important, while being cautious that it doesn't become a "race to the bottom" where only the most basic things work everywhere, while things break as soon as you add something simple or obvious. Mailing lists are such a versatile medium: They can be used with plenty of MUAs, processed and used (!) in many different ways, that's what makes them so valuable for technical people, but also for novices who have started understanding _what_ they're using. Oh, and don't get me wrong: Mail is no replacement for a source control system, but we're not talking about source control, we're talking about mailing list etiquette, in a polite, humble, often technical and sometimes funny way. :-) _____________________________________ < I ate your 80 column punched cards! > ------------------------------------- \ . _ . \ |\_|/__/| / / \/ \ \ /__|O||O|__ \ |/_ \_/\_/ _\ | | | (____) | || \/\___/\__/ // (_/ || | || | ||\ \ //_/ \______// __ || __|| (____(____) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ...