Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 5 Sep 2020 17:26:47 -0400
From:      Ed Maste <emaste@freebsd.org>
To:        Warner Losh <imp@bsdimp.com>
Cc:        Kevin Bowling <kevin.bowling@kev009.com>, src-committers <src-committers@freebsd.org>,  svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org>
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...
Message-ID:  <CAPyFy2DDjNFR8u4ph_w3Cdsbx6cwKms61MOhLdSCPfQDJyBFKA@mail.gmail.com>
In-Reply-To: <CANCZdfprNmczi0mQ7r%2B02inKD4hq9Atn4Zkii9id42iFzxkq-w@mail.gmail.com>
References:  <202009012119.081LJERb018106@repo.freebsd.org> <95844C00-D10A-456D-AD29-DF572043074F@fh-muenster.de> <20200902020507.GA38274@FreeBSD.org> <eba32e79-4b90-ecce-7bbb-455f691d4444@FreeBSD.org> <20200902180626.GA88595@FreeBSD.org> <6124a908-25a5-e023-16da-7963ba229b7f@FreeBSD.org> <08636D5E-AA07-4AE7-B5AC-656B08CF564B@fh-muenster.de> <20200903024226.GA54078@FreeBSD.org> <60ea593f-8258-e30d-b897-f162168b44d3@cs.duke.edu> <20200905010510.GA26297@lonesome.com> <CANCZdfo8km1ahTSajJpLhyFyYyQsPr-ZwMWRZx_jmLGdRpc=WA@mail.gmail.com> <CAK7dMtCAktXP4wMDVfC8FeqnEwtMase7kY6Z=-4MazVQQWdXDQ@mail.gmail.com> <CAPyFy2Ce7AJ9y2KCC8=6oWW%2BFhPBV418RjWun1b36HPLuXpnig@mail.gmail.com> <CANCZdfprNmczi0mQ7r%2B02inKD4hq9Atn4Zkii9id42iFzxkq-w@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, 5 Sep 2020 at 16:41, Warner Losh <imp@bsdimp.com> 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?

> 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).

> 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 before. 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.



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAPyFy2DDjNFR8u4ph_w3Cdsbx6cwKms61MOhLdSCPfQDJyBFKA>