[PATCHv2] Vimrc config with GNU formatting

Yury Gribov y.gribov@samsung.com
Thu Sep 11 16:07:00 GMT 2014


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
> <richard.guenther@gmail.com>  wrote:
>> >On Wed, Sep 10, 2014 at 10:09 AM, Yury Gribov<y.gribov@samsung.com>
>> 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



More information about the Gcc-patches mailing list