From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:53933) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKMqW-0003xx-0T for qemu-devel@nongnu.org; Wed, 29 Jul 2015 04:36:16 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZKMqS-00085S-Hu for qemu-devel@nongnu.org; Wed, 29 Jul 2015 04:36:15 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36044) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZKMqS-000856-Dq for qemu-devel@nongnu.org; Wed, 29 Jul 2015 04:36:12 -0400 From: Markus Armbruster References: <1435782155-31412-1-git-send-email-armbru@redhat.com> <1435782155-31412-38-git-send-email-armbru@redhat.com> <55B14005.9090909@redhat.com> <87twsown2f.fsf@blackfin.pond.sub.org> <55B7C054.5030809@redhat.com> Date: Wed, 29 Jul 2015 10:36:10 +0200 In-Reply-To: <55B7C054.5030809@redhat.com> (Eric Blake's message of "Tue, 28 Jul 2015 11:48:04 -0600") Message-ID: <87pp3bicn9.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH RFC v2 37/47] qapi: De-duplicate parameter list generation List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: kwolf@redhat.com, berto@igalia.com, qemu-devel@nongnu.org, mdroth@linux.vnet.ibm.com Eric Blake writes: > On 07/28/2015 05:15 AM, Markus Armbruster wrote: > >>> Yeah, avoiding line wraps consumes fewer source bytes (fewer runs of >>> spaces), but the space isn't being wasted by storing generated files in >>> git, nor does the C compiler care which layout we use. And honestly, >>> it's easier to spot changes in a vertical list than it is on a long >>> horizontal line, if a parameter gets added (or removed, although adding >>> is the more likely action with qapi). >> >> Number of source bytes is not an issue. >> >> The generators make no effort to wrap source lines, except in the >> qapi_event_send_FOO()'s parameter lists. >> >> We could preserve that one-off. We could extend it to more places that >> can generate long lines, saddling the generation code with indentation >> concerns. I don't want to write such code, and I don't want to maintain >> it. >> >> Instead, why not keep the generators straightforward, and feed their >> result to indent when "pretty" is wanted? Requires an indent profile >> matching QEMU style. > > Long lines aren't the end of the world. They may be harder to read when > diffing pre- and post-patch generated output to see if a generator > change makes sense, but you have a point that line wrapping is more > maintenance. So you win; keep the long lines, and if someone wants > wrapping, they can (re-)add it as a later patch series. Settled. Aside: diff-mode can color the parts of the changed lines that actually differ. Indispensable, and not just for long lines.