Add a tentative .clang-format for LilyPond.

Add a tentative .clang-format for LilyPond.

To try it out, run

  clang-format -i lily/include/*[ch] lily/*.cc

[lemzwerg, 2020-01-27 10:07:20]

For which clang-format version is this format file?  It doesn't work with 7.0.1,
for example.  Please add this information to the file.

[hanwenn, 2020-01-29 06:45:53]

On 2020/01/27 10:07:20, lemzwerg wrote:
> For which clang-format version is this format file?  It doesn't work with
7.0.1,
> for example.  Please add this information to the file.

$ clang-format --version
clang-format version 9.0.0 (Fedora 9.0.0-1.fc31)

can you pinpoint which statements cause problems? We could leave out the default
values for enhanced compatibility.

[hanwenn, 2020-01-29 06:55:54]

just the overrides

[lemzwerg, 2020-01-29 07:41:40]

> just the overrides

The new version works just fine.  Shall I still inspect the previous version for
problematic statements?

The output looks good.  BTW, for the sake of Emacs, it would be nice if two
spaces after a full dot could be retained in comments.  Does such an option
exist?

[Dan Eble, 2020-01-29 12:19:54]

On 2020/01/29 07:41:40, lemzwerg wrote:
> The output looks good.  BTW, for the sake of Emacs, it would be nice if two
> spaces after a full dot could be retained in comments.  Does such an option
> exist?

Retaining everything with ReflowComments:false might be the only way.
https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html

[hanwenn, 2020-01-30 09:24:17]

reflow

[hanwenn, 2020-01-31 09:39:33]

On 2020/01/29 12:19:54, Dan Eble wrote:
> On 2020/01/29 07:41:40, lemzwerg wrote:
> > The output looks good.  BTW, for the sake of Emacs, it would be nice if two
> > spaces after a full dot could be retained in comments.  Does such an option
> > exist?
> 
> Retaining everything with ReflowComments:false might be the only way.
> https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html

I've applied your suggestion; PTAL.

[Dan Eble, 2020-01-31 12:35:45]

On 2020/01/31 09:39:33, hanwenn wrote:
> I've applied your suggestion; PTAL.

If Werner likes it, I'm fine with it.  I haven't tried it myself because I want
to avoid being drawn into discussing the details of the style, but I like seeing
movement toward a better process.

[hanwenn, 2020-01-31 18:06:00]

On 2020/01/31 12:35:45, Dan Eble wrote:
> On 2020/01/31 09:39:33, hanwenn wrote:
> > I've applied your suggestion; PTAL.
> 
> If Werner likes it, I'm fine with it.  I haven't tried it myself because I
want
> to avoid being drawn into discussing the details of the style, but I like
seeing
> movement toward a better process.

that's great to hear. Will james pick this up automatically now, or does it need
an LGTM?

[Carl, 2020-01-31 18:33:38]

IIUC, this is a .clang-format that can be (but is not required to be) used to
format source code and prevent comments about formatting.

At this point, we are not enforcing a shift to clang-format as the code standard
for LilyPond.

If this is true, LGTM.

If we are enforcing a shift to clang-format, then I think we need an LGTM from
David K.

[hanwenn, 2020-01-31 18:35:18]

On 2020/01/31 18:33:38, Carl wrote:
> IIUC, this is a .clang-format that can be (but is not required to be) used to
> format source code and prevent comments about formatting.
> 
> At this point, we are not enforcing a shift to clang-format as the code
standard
> for LilyPond.
> 
> If this is true, LGTM.
> 
> If we are enforcing a shift to clang-format, then I think we need an LGTM from
> David K.

correct.

[Carl, 2020-01-31 18:37:33]

On 2020/01/31 18:06:00, hanwenn wrote:

>  Will james pick this up automatically now, or does it need
> an LGTM?

James should pick it up automatically now.

[lemzwerg, 2020-02-01 07:07:32]

> If Werner likes it, I'm fine with it.

I do like it, and it is completely non-intrusive since it gets used locally only
for those people who set up a proper git hook (or call `clang-format` manually).

[Dan Eble, 2020-02-04 20:35:40]

I'm running some of my patches through clang-format as I prepare to push them.

This is an example of a kind of change it wants to make:

-  const array<int, 2> key {column_rank, dir};
+  const array<int, 2> key{column_rank, dir};

Note the space after key.  The setting that controls this is
SpaceBeforeCpp11BracedList.  Am I correct that we should use a space here for
consistency with historical style?

More examples of the effect of the option are in the docs:
https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html

[hanwenn, 2020-02-04 22:18:23]

On 2020/02/04 20:35:40, Dan Eble wrote:
> I'm running some of my patches through clang-format as I prepare to push them.
> 
> This is an example of a kind of change it wants to make:
> 
> -  const array<int, 2> key {column_rank, dir};
> +  const array<int, 2> key{column_rank, dir};
> 
> Note the space after key.  The setting that controls this is
> SpaceBeforeCpp11BracedList.  Am I correct that we should use a space here for
> consistency with historical style?
> 
> More examples of the effect of the option are in the docs:
> https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html

historically, we didn't have C++11, so this wasn't an issue. I'm fine with
whatever you pick.

With the space seems more coherent with the s p a c e y  GNU style.

[dak, 2020-02-04 23:40:03]

On 2020/02/04 22:18:23, hanwenn wrote:
> On 2020/02/04 20:35:40, Dan Eble wrote:
> > I'm running some of my patches through clang-format as I prepare to push
them.
> > 
> > This is an example of a kind of change it wants to make:
> > 
> > -  const array<int, 2> key {column_rank, dir};
> > +  const array<int, 2> key{column_rank, dir};
> > 
> > Note the space after key.  The setting that controls this is
> > SpaceBeforeCpp11BracedList.  Am I correct that we should use a space here
for
> > consistency with historical style?
> > 
> > More examples of the effect of the option are in the docs:
> >
https://releases.llvm.org/9.0.0/tools/clang/docs/ClangFormatStyleOptions.html
> 
> historically, we didn't have C++11, so this wasn't an issue. I'm fine with
> whatever you pick.
> 
> With the space seems more coherent with the s p a c e y  GNU style.

Personally, the best of two worlds would be if a ping-pong between our current
Astyle and clang-format would end up stable after one application of each.  That
way, putting the code base through both Astyle and clang-format semi-regularly
would put it into a form where users of either formatting tool could contribute
their changes without affecting already formatted code in the same file.

[Dan Eble, 2020-02-05 00:00:17]

On 2020/02/04 23:40:03, dak wrote:
> Personally, the best of two worlds would be if a ping-pong between our current
> Astyle and clang-format would end up stable after one application of each. 
That
> way, putting the code base through both Astyle and clang-format semi-regularly
> would put it into a form where users of either formatting tool could
contribute
> their changes without affecting already formatted code in the same file.

+1.  I actually tried that earlier today, and there were lots of differences.  I
was using astyle 3.1 because that's what I had, so I'm not sure it represents
the ideal, but I'm confident that this clang-format file needs some work
regardless.  It's a good start, though.