From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18741 invoked by alias); 11 Sep 2014 16:07:58 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 18732 invoked by uid 89); 11 Sep 2014 16:07:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 X-HELO: mailout2.w1.samsung.com Received: from mailout2.w1.samsung.com (HELO mailout2.w1.samsung.com) (210.118.77.12) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (DES-CBC3-SHA encrypted) ESMTPS; Thu, 11 Sep 2014 16:07:56 +0000 Received: from eucpsbgm2.samsung.com (unknown [203.254.199.245]) by mailout2.w1.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTP id <0NBQ00F2EVLVG190@mailout2.w1.samsung.com> for gcc-patches@gcc.gnu.org; Thu, 11 Sep 2014 17:10:43 +0100 (BST) Received: from eusync4.samsung.com ( [203.254.199.214]) by eucpsbgm2.samsung.com (EUCPMTA) with SMTP id D4.96.15956.7D8C1145; Thu, 11 Sep 2014 17:07:51 +0100 (BST) Received: from [106.109.9.145] by eusync4.samsung.com (Oracle Communications Messaging Server 7u4-24.01(7.0.4.24.0) 64bit (built Nov 17 2011)) with ESMTPA id <0NBQ00BHIVH2WEB0@eusync4.samsung.com>; Thu, 11 Sep 2014 17:07:51 +0100 (BST) Message-id: <5411C8D9.5030109@samsung.com> Date: Thu, 11 Sep 2014 16:07:00 -0000 From: Yury Gribov User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-version: 1.0 To: Richard Biener Cc: GCC Patches , Laurynas Biveinis , Jeff Law , Segher Boessenkool , Bernhard Reutner-Fischer , Trevor Saunders , Mike Stump Subject: Re: [PATCHv2] Vimrc config with GNU formatting References: <540863C1.4000909@samsung.com> <54100735.5040700@samsung.com> <541174FC.6080400@samsung.com> In-reply-to: <541174FC.6080400@samsung.com> Content-type: text/plain; charset=utf-8; format=flowed Content-transfer-encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-09/txt/msg00950.txt.bz2 On 09/11/2014 02:10 PM, Yury Gribov wrote: > On 09/11/2014 01:18 PM, Richard Biener wrote: > On Thu, Sep 11, 2014 at 11:06 AM, Richard Biener > wrote: >> >On Wed, Sep 10, 2014 at 10:09 AM, Yury Gribov >> wrote: >>> >>Hi all, >>> >> >>> >>This is a second version of patch which adds a Vim config >>> (.local.vimrc) >>> >>to root folder to allow automatic setup of GNU formatting for >>> C/C++/Java/Lex >>> >>GCC files. >>> >> >>> >>I've updated the code with comments from Richard and Bernhard >>> (which fixed >>> >>formatting >>> >>of lonely closing bracket). >>> >> >>> >>The patch caused a lively debate with Segher who wanted >>> .local.vimrc to not >>> >>be enabled >>> >>by default. We basically have two options: >>> >>1) put .local.vimrc to root (just like .dir-locals.el config for >>> Emacs) >>> >>2) put both .local.vimrc and .dir-locals.el to contrib and add >>> Makefile >>> >>targets >>> >>to create symlinks in root folder per user's request >>> >>I personally prefer 2) because this would IMHO improve the quality of >>> >>patches >>> >>(e.g. no more silly tab-whitespace formatting bugs). >>> >> >>> >>Thoughts? Ok to commit? >> > >> >It doesn't handle indenting switch/case correctly. I get >> > >> > switch (x) >> > { >> > case X: >> > { >> > int foo; >> >... >> > >> >that is, the { after the case label is wrongly indented. The same >> happens >> >for >> > { >> > { >> > } >> > } >> > >> >we seem to get two soft-tabs here. >> >> setlocal cinoptions=>s,n-s,{s,:s,=s,g0,hs,p5,t0,+s,(0,u0,w1,m0 >> >> does better but still oddly handles > > Also fails for > > if (1) > { > x = 2; > } Ok, it tooks some time. Basically we want brace symbol to behave differently in two contexts: 1) not add any additional offset when not following control flow operator: void f () { int x; { } } 2) but add shifttab otherwise: void f() { if (1) { } } My understanding is that {N looks too rigid and always adds the same amount to current indent. Thus we see parasitic whites in the first case. I wonder what would be the best way to handle this. We could just live with that (free {}'s are rare anyway) or I could try to hack a custom indentexpr (this will of course increase the complexity of patch). -Y