From owner-svn-src-head@freebsd.org Sat Sep 5 22:28:31 2020 Return-Path: Delivered-To: svn-src-head@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 BB00D3D8659; Sat, 5 Sep 2020 22:28:31 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id 4BkTht404Mz45Yd; Sat, 5 Sep 2020 22:28:30 +0000 (UTC) (envelope-from mike@karels.net) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id 085MSLh6023456; Sat, 5 Sep 2020 17:28:21 -0500 (CDT) (envelope-from mike@karels.net) Message-Id: <202009052228.085MSLh6023456@mail.karels.net> To: Ed Maste cc: Warner Losh , src-committers , svn-src-all , svn-src-head From: Mike Karels Reply-to: mike@karels.net Subject: Re: svn commit: r365071 - in head/sys: net net/altq net/route net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgraph... In-reply-to: Your message of Sat, 05 Sep 2020 17:26:47 -0400. MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <23454.1599344901.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Sat, 05 Sep 2020 17:28:21 -0500 X-Rspamd-Queue-Id: 4BkTht404Mz45Yd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of mike@karels.net designates 216.160.39.52 as permitted sender) smtp.mailfrom=mike@karels.net X-Spamd-Result: default: False [-2.25 / 15.00]; HAS_REPLYTO(0.00)[mike@karels.net]; ARC_NA(0.00)[]; NEURAL_SPAM_SHORT(0.01)[0.011]; FREEFALL_USER(0.00)[mike]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:216.160.39.52]; NEURAL_HAM_LONG(-1.00)[-1.005]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[karels.net]; RCPT_COUNT_FIVE(0.00)[5]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; NEURAL_HAM_MEDIUM(-1.05)[-1.053]; RCVD_NO_TLS_LAST(0.10)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:209, ipnet:216.160.36.0/22, country:US]; RCVD_COUNT_TWO(0.00)[2]; MAILMAN_DEST(0.00)[svn-src-head,svn-src-all] X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 22:28:31 -0000 > From: Ed Maste > Date: Sat, 5 Sep 2020 17:26:47 -0400 > Subject: Re: svn commit: r365071 - in head/sys: net net/altq net/route > net80211 netgraph netgraph/atm netgraph/atm/ccatm netgraph/atm/sscfu > netgraph/atm/sscop netgraph/atm/uni netgraph/bluetooth/common netgraph.= .. > On Sat, 5 Sep 2020 at 16:41, Warner Losh wrote: > > > >> Fixed: > >> - *_FOREACH now has a space before (, equivalent to for (;;) > > > > Except pretty much everywhere we don't have a space there... > Why not? Why should TAILQ_FOREACH have a different style from a for loop= ? Because it is a macro, maybe? And all the other invocations are done that way. > > broke all alignment of variables and comments that were done. > > broke purposely outdented code in statistics function > > broke all err() calls to wrap too much > I had all of these under "indifferent" already, or are more examples > of already covered cases (e.g. what seems to be string argument > wrapping). I don't consider those indifferent. > > extra headers still included. > This is probably not the job of a formatter though. > >> - function argument wrapping (see write_glyph_buf) > >> - leading indentation and args-per-line (print_font_info) > > > > An interesting experiment, but there's far more worse after than befor= e. The rearranging of carefully aligned elements is an especially galling = change for some people (myself included). > I disagree this is far worse. If we fixed the wrapping on the second > line of if/for conditions I'd say the benefit of letting tooling take > care of the formatting outweighs the perhaps slightly less appealing > formatting. I'm with Warner on this. I saw a lot to dislike in the changes, and very little actual improvement. If we were starting from scratch, I might be willing to accept the changes to have a formatter (albeit begrudingly), bu= t we are not starting from scratch. The churn would be horrible, and the benefit very little in comparison. Interesting experiment, but let's keep it just an experiment. Mike