<div dir="ltr">Ok I totally understand it. So in my point of view clang-format is extremally powerfull tool mainly because of configuration. <div><br><div>For example when colligues said "it would be nice to have one liner getters, and to not merge normal functions into one line". On that point I didn't belive that configuration is smart enough to handle that case, but then I saw SFS_Inline was exactly the thing I was looking for.</div></div><div>So I don't know what is the real cost of adding new feature, I will probably look at code some day and try to understand the real costs, but anyway, clang-format is a very usefull tool, and I hope it will be more configurable in the future.</div><div><br></div><div>Piotr</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-13 21:12 GMT+01:00 Daniel Jasper <span dir="ltr"><<a href="mailto:djasper@google.com" target="_blank">djasper@google.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Would be that much effort, but not sure clang-format wants to commit to it. At some point, I have actually noted down the requirements for additional options:<div><br></div><div><a href="http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options" target="_blank">http://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options</a><br></div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 9:00 PM, Piotr Padlewski <span dir="ltr"><<a href="mailto:piotr.padlewski@gmail.com" target="_blank">piotr.padlewski@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">Hi folks,<div>so recently I was enforcing clang-format in the team that I work with, and we found out 2 things that can't be configured and that are formated not in the way that we would like to:</div><div><br></div><div>1. typedefs</div><div>so many times people use style like this for typedefs</div><div><br></div><div><div>struct Predicate</div><div>{</div><div> typedef std::shared_ptr<Predicate> Ptr;</div><div> typedef std::map<std::string, std::string> Params;</div><div>};</div></div><div><br></div><div>So as you can see the type names are aligned, and sometimes there is larger space between name and type.</div><div>I guess this can be solved using using like this:</div><div><div>struct Predicate</div><div>{</div><div> using Ptr = std::shared_ptr<Predicate>; </div><div> using Params = std::map<std::string, std::string>;</div><div>};</div></div><div><br></div><div>because of the = align, but sometimes you can't use c++11 etc so it's not the answer to every case.</div><div><br></div><div>2. The second thing is about macros and the operator ## - on default it is glued </div><div><br></div><div><div>#define CREATE_EVENT_ACCESSORS(Field, Type) \</div><div> struct Field##Accessors \</div><div> { \</div><div> template <class E> \</div><div> const Type &get(const E &e) const \</div><div> { \</div><div> return e.ref##Field(); \</div><div> } \</div><div> template <class E> \</div><div> void set(E &e, const Type &value) \</div><div> { \</div><div> e.set##Field(value); \</div><div> } \</div><div> };</div></div><div><br></div><div>and there is no way to configure it as normal operator (with spaces arround).</div><div>My question is: would it be simple to add this options? If it woudn't require too much effort I would like to add this features.</div><span><font color="#888888"><div><br></div><div>Piotr</div><div><br></div></font></span></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>