<div dir="ltr">I think Richard is right, though.<div><br></div><div>AllowShortFunctionsOnASingleLine should simply trump AlwaysBreakAfterReturnType. Renaming the latter might or might not make sense, but I don't think introducing an enum for it is necessary.</div><div><br></div><div>(Also BreakAfterReturnType=never would be very misleading as clang-format would break after the return type, but that is beside the point).</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jan 5, 2015 at 11:20 PM, Adam McKee <span dir="ltr"><<a href="mailto:Adam.Matthew.McKee@gmail.com" target="_blank">Adam.Matthew.McKee@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>If you (re-)read my original post, I wasn't actually asking for "AlwaysBreakAfterReturnType" to remain, yet act differently when "AllowShortFunctionsOnASingleLine" is indicated.  I suggested renaming it to "BreakAfterReturnType", with available settings "always", "never", and "multiline", where "multiline" means break after return type unless "AllowShortFunctionsOnASingleLine=true", and the function can fit on a single line.</div><div><br></div><div>Anyway I've been formatting with AlwaysBreakAfterReturnType, and I think I can live with the loss of the simple one-liners in the class declarations.  It's just really nice to be freed from having to dink around with the formatting manually, and knowing it's all consistent.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jan 4, 2015 at 3:27 AM, Richard Smith <span dir="ltr"><<a href="mailto:richard@metafoo.co.uk" target="_blank">richard@metafoo.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div>I don't think a new option is necessary here; if you set both <span style="font-size:13px">AllowShortFunctionsOnASingleLi</span><span style="font-size:13px">ne and </span><span style="font-size:13px">AlwaysBreakAfterReturnType, the only reasonable thing you could mean is for the former to overrule the latter. There doesn't seem to be any inconsistency in saying that AllowShortFunctionsOnASingleLine has higher priority than AlwaysBreakAfterReturnType.</span></div><div><span style="font-size:13px"><br></span></div><div><span style="font-size:13px">(OK, there's a remote possibility that you might mean that constructors, destructors, and conversion functions can go on a single line, but functions with return types can't, which is what clang-format does today, but I don't think that's a reasonable formatting style.)</span></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div>On Tue, Dec 30, 2014 at 10:01 PM, Adam McKee <span dir="ltr"><<a href="mailto:Adam.Matthew.McKee@gmail.com" target="_blank">Adam.Matthew.McKee@gmail.com</a>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div><div dir="ltr"><div>It does make sense to me that it's impractical to have clang-format support all the formatting styles people like.  I think if I was maintaining this program, I'd want a stronger justification for increasing the number of configuration parameters than I would for making an existing parameter able to better co-operate with another existing parameter.</div><div><br></div>I haven't looked at the source for clang-format yet, but I don't rule out having a go at making a patch.  If I do that I'll surely send it to you, to get your feedback.<div><br></div><div>Anyhow, Happy New Year!</div><div><br></div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Dec 26, 2014 at 1:17 PM, Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">As for the option: It has never been the intention of clang-format to support any style that someone somewhere has come up with. We'd rather support a limited set of established styles really well. You could probably make an argument that we have already lost that war, looking at the number of options that clang-format already has. However, we still have the general rule that we'd rather introduce options only for stuff that is used in big (ideally open-source) projects or publicly available style guides. Now again, I don't think this option will have a terribly high maintenance effort, but it is also not trivial. At least until we are able to pull out a better abstraction for "do this if stuff fits/doesn't fit on one line". I still haven't made up my mind. Are you willing to prepare a patch showing what this would actually look like?<div><br></div><div>As for a plugin mechanism: I have not come up with a good way to do this yet. Especially, I have so far failed to see what the right level of abstraction would be here. Basically every single of such options requires manipulating a separate set of things. And I am also unsure whether this solves anything. Somebody writing such a plugin will still file the same bugs if we change a different part of clang-format breaking the plugin's behavior. And then we are in pretty much the same situation except that we might not have the test cases we need and no good way to reproduce the behavior.</div></div><div><div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Dec 25, 2014 at 4:19 PM, mobi phil <span dir="ltr"><<a href="mailto:mobi@mobiphil.com" target="_blank">mobi@mobiphil.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra">first, hope that everybody is having a lovely Xmass time.
</div><div class="gmail_extra"><br></div><div class="gmail_extra">it is on my todo list to hack the clang-format tool. Wonder if there is some plugin mechanism in place (or if not, why not think about), that would accommodate situations presentend by the original poster. It is in my opinion a healthy middle way. I think once one would discover the power of the tool, would find tons of ways and reasons to deviate from the existing bit limited range of options.</div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>
</div></div><br></div></div><span>_______________________________________________<br>
cfe-dev mailing list<br>
<a href="mailto:cfe-dev@cs.uiuc.edu" target="_blank">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></span></blockquote></div><br></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>