[PATCH] Update block formatting to behave like Xcode

[Daniel Jasper]

================
Comment at: include/clang/Format/Format.h:225
@@ -224,1 +224,3 @@
 
+  /// \brief Compress the selector parts when more than two inline blocks are specified
+  bool ObjCXcodeBlockFormat;
----------------
KingOfBrian wrote:
> djasper wrote:
> > I this style documented somewhere? There are many corner cases that you aren't explicitly testing. E.g. what if there are non-block selectors in between? What if the selectors before the first block do not fit on one line?
> > 
> > ObjCXcodeBlockFormat is not a good name. It would be good to have something that actually describes the behavior. Like this it is not really discoverable. And this does not really change the behavior of blocks in general, but the behavior of blocks in method exprs, IIUC.
> > 
> > Also, the comment needs to be quite a bit more elaborate.
> I haven't been able to find it documented anywhere, I looked around for a while. But it's been the same formatting in Xcode since blocks were introduced. I'll add some more tests for long selector-parts and see how it behaves.
> 
> I'm a bit stumped on the naming for behavior so I opted to name it based on the origin -- similar in approach to `allman` vs `soustroup`. I'm not sure there's a name that is discoverable, since the difference between this and the current google style is pretty nuanced. Would changing it to a style enumeration be more acceptable?
> 
> I added the prefix ObjC to imply that this only affects the behavior of blocks in method exprs, obviously that was not clear enough.
> 
> Also, reading the comment again, it's wrong, sorry about that. The comment explains the inverse of one of the two behavior changes - I'll take another stab at it, but without a good name for the flag, I'm a bit stumped. Let me think about it.
The fundamental question is, whether we want clang-format to support this style. I don't think it is useful to support it, just because it is what some other tool creates. That would mean that clang-format would have to implement all the flaws of other indentation tools, which we certainly do not want to do.

That being said, if this is widely used and ideally documented somewhere, it might be worth adding. But we certainly need to define it precisely in the comment (especially is there is no other documentation) and we need to make it work with a non-zero column limit.

http://reviews.llvm.org/D9237

EMAIL PREFERENCES
  http://reviews.llvm.org/settings/panel/emailpreferences/