<br><br><div class="gmail_quote">On Fri, Dec 7, 2012 at 7:40 PM, Sean Silva <span dir="ltr"><<a href="mailto:silvas@purdue.edu" target="_blank">silvas@purdue.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Derp, sorry for the novel of my thought process on the issue.<br>
<br>
tl;dr: Yes, we definitely will need it when working with any<br>
nontrivial real codebase. Implement it when it is blocking forward<br>
progress. Make the delimiter for "manually formatted" regions<br>
configurable (like a regex) and have the command line tool support<br>
various existing styles through a command line flag and not introduce<br>
yet another "don't format this" marker.<br>
<br>
Remember that a large contributor to clang's success is the fact that<br>
it is sufficiently close to GCC to be able to pretty much immediately<br>
be useful for projects that use GCC. Probably without going to the<br>
extent of command-line compatibility with existing formatting tools, I<br>
think that having clang-format be useful for existing codebases<br>
without requiring the changes to their code (i.e. changing the "don't<br>
format this" comments to some marker specific to clang-format) would<br>
be a huge win.<br>
<span class="HOEnZb"><font color="#888888"><br>
-- Sean Silva<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
On Fri, Dec 7, 2012 at 1:20 PM, Sean Silva <<a href="mailto:silvas@purdue.edu">silvas@purdue.edu</a>> wrote:<br>
> I'm not convinced that there are that many situations where this kind<br>
> of special-case formatting is ever completely necessary. Let's try to<br>
> avoid as long as possible adding things to clang-format that will<br>
> allow subjectivity in source layout ;) Let's keep things completely<br>
> automated.<br>
><br>
> Maybe it's worth teaching clang-format about this situation as a<br>
> special case? Alternatively, as Konstantin points out, putting the<br>
> returns on their own line indented would lead to an equally (ore more)<br>
> readable layout, and I think it would be perfectly acceptable for<br>
> clang-format to default to doing something like that.<br>
><br>
> Also, there are a lot of coding styles that do this kind of alignment<br>
> for nearly all declarations (e.g. for all the `=` when declaring local<br>
> variables), so by the time that clang-format is in production across a<br>
> variety of projects, I imagine that support for "aligned" layouts like<br>
> these switches will be a piece of toggleable generic functionality<br>
> (like maybe through an astmatcher or something).<br>
><br>
> A slightly more thorny case I think is distinguishing a situation<br>
> where we just have a bag of labels like<br>
><br>
> case Foo:<br>
> case Bar:<br>
> case Baz:<br>
>   return Qux;<br>
><br>
> from a situation where the case labels have some natural grouping<br>
> which leads naturally to a more condensed layout like<br>
><br>
> case EAX: case ECX: case EDX: case EBX:<br>
> case EBP: case ESP: case ESI: case EDI:<br>
>   return GPR;<br>
><br>
> An even nastier example is<br>
> <<a href="http://clang.llvm.org/doxygen/Lexer_8cpp_source.html#l02851" target="_blank">http://clang.llvm.org/doxygen/Lexer_8cpp_source.html#l02851</a>>, where a<br>
> condensed layout is used with *comments* put in place of "missing"<br>
> labels which are handled elsewhere to maintain the logical<br>
> alphabetical alignment and exhibit that those other cases are being<br>
> handled elsewhere. Even with the benefit of an AST, supporting this<br>
> kind of thing seems extraordinarily difficult ("AI-complete"?).<br>
> However, this particular situation is *extremely* compelling, because<br>
> pretty much any other layout would obscure the fact that those<br>
> specific other letters are handled elsewhere.<br>
><br></div></div></blockquote><div><br>Regarding this specific example: I think it could be "simple" to just treat the whole line as "unbreakable" whenever there are several "case" on it.<br>
<br>That is, if two 'case' are on the same physical line, just treat this whole line as a black box, and contend yourself with aligning it first non-blank character.<br><br>-- Matthieu<br> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">
> The lexer example convinces me that we *will* need some escape hatch<br>
> for the formatter; I guess the question then is "does now feel like<br>
> the right time?". I think a reasonable criterion for this is "when it<br>
> is needed, implement it". I.e. when you start reformatting real code<br>
> and the result is unacceptable due some situation that can't be<br>
> reasonably addressed in an automated fashion (like the lexer situation<br>
> above).<br>
><br>
> Btw, w.r.t. bikeshedding over what the escape hatch should look like,<br>
> you can circumvent the entire issue and just make it configurable<br>
> (like passing in a regex or something). I think it is safe to have the<br>
> default inside the library be no escape hatch unless one is explicitly<br>
> provided. The clang-format commandline program can then keep a table<br>
> of common preexisting ones and use a command line switch to choose<br>
> between them (and just pick one as the default for projects "natively"<br>
> using clang-format on the command line). Remember<br>
> <<a href="http://xkcd.com/927/" target="_blank">http://xkcd.com/927/</a>>.<br>
><br>
> -- Sean Silva<br>
><br>
> On Fri, Dec 7, 2012 at 11:18 AM, Daniel Jasper <<a href="mailto:djasper@google.com">djasper@google.com</a>> wrote:<br>
>> Hi all,<br>
>><br>
>> although I think we can make clang-format (clang/lib/Format) format more and<br>
>> more pieces of C++ according to a specific style, I am convinced that there<br>
>> are cases where automatic formatting is not the right solution.<br>
>><br>
>> An example is:<br>
>> <a href="http://clang.llvm.org/doxygen/ParseExpr_8cpp-source.html" target="_blank">http://clang.llvm.org/doxygen/ParseExpr_8cpp-source.html</a> line 60-90. Here,<br>
>> careful human thought leads to much more readable code then simply following<br>
>> a style guide.<br>
>><br>
>> In order to handle such cases and still be able to auto-format entire files,<br>
>> I propose to add certain markers around areas of a file that clang-format<br>
>> should not touch. Does anyone have thoughts on this? How would we best<br>
>> design this? Add special comments like "// NO clang-format {"?<br>
>><br>
>> Cheers,<br>
>> Daniel<br>
>><br>
>><br>
>><br>
>> _______________________________________________<br>
>> cfe-dev mailing list<br>
>> <a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
>> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
>><br>
_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu">cfe-dev@cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/cfe-dev</a><br>
</div></div></blockquote></div><br>