From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11694 invoked by alias); 3 Feb 2018 16:15:47 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 11593 invoked by uid 89); 3 Feb 2018 16:15:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=impression, lucky X-HELO: mail-lf0-f48.google.com Received: from mail-lf0-f48.google.com (HELO mail-lf0-f48.google.com) (209.85.215.48) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sat, 03 Feb 2018 16:15:32 +0000 Received: by mail-lf0-f48.google.com with SMTP id a204so35911510lfa.2 for ; Sat, 03 Feb 2018 08:15:27 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=vfbYBfyfW+gIN8zTCC3Y+RVgKHzgtxCdCSPKJe7IGPY=; b=mwKYOU0M7dRkFUhYgtOog+2WlenoiDxN6lId+FqdNtVD6Tx3pCsNBE7mqtn9hO0dpE 4+tPa4DTmalXvIvpWeiRLzZAO/khskEJq7eIMo+XQgIZBjy9QRzj2chY5tuj6jpRR5Xv uor7g5IPeHTBVX7hWv5uDVpUodBon/+eU2T/OhxOwfMxgf8c7JLCcWQ0kvkp97MkUKHW x/5Z2LddH5+k5I9Z6RbwU4/GrTVp2Tm8ySS5OQzE6HglwBn9HN1+ysSNqL/99F3qgdTf p1Q41K+YSYC9b0lbI2lQqcIt5vlgN3LMrajfVuq3bwXID508txJLFH5kmX13C/sfKFp8 3ntw== X-Gm-Message-State: AKwxytd8/pySWponIoYvUppo42pDmU7iIWKAjpmX1eRLRrzsDOQn7UPI QQ2g/3nrjxZYe71uvYTYq3EHa9m2EUKlBbOsDaEW0Tax X-Google-Smtp-Source: AH8x226HhGlNBZcKXRjNSZ8K91vfy0tRpNjoE8H9Nf7RgHc3Gi+dTbeMNAsFQAFS4EgfL+/PdP3OlLw5QYAACZ45bA0= X-Received: by 10.25.224.17 with SMTP id x17mr26702195lfg.91.1517674525994; Sat, 03 Feb 2018 08:15:25 -0800 (PST) MIME-Version: 1.0 Received: by 10.25.216.93 with HTTP; Sat, 3 Feb 2018 08:15:25 -0800 (PST) In-Reply-To: <87b8b9de-1a29-0470-a65b-784475502473@simark.ca> References: <1516346545-8217-1-git-send-email-b7.10110111@gmail.com> <87b8b9de-1a29-0470-a65b-784475502473@simark.ca> From: Ruslan Kabatsayev Date: Sat, 03 Feb 2018 16:15:00 -0000 Message-ID: Subject: Re: [PATCH v3] Align natural-format register values to the same column To: Simon Marchi Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg00051.txt.bz2 On 3 February 2018 at 18:55, Simon Marchi wrote: > On 2018-02-03 06:43 AM, Ruslan Kabatsayev wrote: >> I'm extremely sorry for making you repeat your comments. I keep >> missing some formatting bits. Are there any known-working options for >> any linter/indenter so that I could automatically check/prettify my >> GDB patches before posting? I've tried astyle, but it somehow messes >> up spaces/tabs and doesn't seem to support half-indenting enum braces >> (or I didn't use the correct options). GNU indent appears to confuse >> C++ references with bitwise OR, putting spaces on both sides, and also >> doesn't want to half-indent enums. > > I don't know of any tool/config that does it right out of the box, but if > you manage to find a solution that works nicely, please share it. The problem > is often that if you run files through an automatic formatter, you'll have a huge > diff of little changes (fix existing style issues, change how things are wrapped, > etc). If there was a way to tell the formatter to only touch the lines that were > touched in your patch, it would be ideal. > > What do you mean by half-indent enum, do you mean that the curly braces are > indented with respect to the enum keywork, like this? > > enum tab_stops > { > value_column_1 = 15, > /* Give enough room for "0x", 16 hex digits and two spaces in > preceding column. */ > value_column_2 = value_column_1 + 2 + 16 + 2, > }; I guess I was still under the impression of 4-space indent between scopes and perceived this additional 2-space indent of braces after enum as a half-indent. I see now that generally the indent is 2 spaces, not 4, so this is actually one full indentation of the braces. > > I've seen inconsistent style in GDB between the above, and this: > > enum tab_stops > { > value_column_1 = 15, > /* Give enough room for "0x", 16 hex digits and two spaces in > preceding column. */ > value_column_2 = value_column_1 + 2 + 16 + 2, > }; Apparently I wasn't too lucky when I was looking for examples how to format enums in the code base and came up with the first instance of "enum opt" in "gdb/mi/mi-cmd-stack.c". Otherwise I'd do it without indenting braces. > > I think the second version makes more sense, because it mimics how it's > done for functions. But I don't know if it should be different if the > enum is declared inside the scope of a function. If your formatter > writes it like the second version, I would be totally fine with it. > >> I've sent a new version of the patch. > > Thanks, I'll look at it later. > > Simon