Maybe one other thing to note in general: I have no strong feelings with respect to code formatting. I don't care where braces are put and when to break lines. What I do care about, however, is that we have a common way of configuring our editors so that we don't oscillate between styles whenever we touch a file which has been edited by somebody with a different or misconfigured editor.
This is where the problem lies: Managing editor configs which do the same thing is not as easy as having a single code formatting tool integrated as plugin into all editors and as part of our CI lint. Then we only need a single config. This is where the statement regarding "sacrificing little subjective/aesthetic issues in favour of a tool supported formatter" comes from. If anybody knows an alternative to clang-format, I am also open for alternatives (emacs is not, I use nvim) > On 17. Apr 2019, at 23:25, Schanzenbach, Martin <[email protected]> > wrote: > > Signed PGP part > > >> On 17. Apr 2019, at 21:08, Christian Grothoff <[email protected]> wrote: >> >> Signed PGP part >> From private discussion with Martin where I pointed out a few style >> issues I didn't like and Martin either created fixes or determined that >> what I wanted was not (yet) possible... >> (forwarding with permission)... >> >> On 4/17/19 3:58 PM, Schanzenbach, Martin wrote: >>> The thing is clang-format is built with the most common styles in >>> mind (including GNU). It does not cover every little corner case and >>> does not want to in order to keep it simple (see >>> https://clang.llvm.org/docs/ClangFormatStyleOptions.html#adding-additional-style-options). >> >> Yes, I did read that in the manual as well. Still, in the "worst case" >> we could consider patching it ourselves, but it would have to be a >> reasonably painful issue to justify that. >> >>> So either we move towards a tool-based solution (idk any other good >>> besides clang-format) and sacrifice such little issues like odd >>> formatting in the case of yoda expressions or just leave it as is. >> Well, the list of sacrifices (= styles generated by the tool that I >> personally don't like) is still a bit long. Regardless, I should start >> by saying that I appreciate your efforts at making it shorter, and I am >> still optimistic that this can be fixed. In the past we tried to get >> there with GNU indent (even patching it!), but ultimately it didn't >> quite work out. My feeling is that GNU indent didn't work in part >> because it ultimately required installing indent with our patches, and >> also in part because it didn't integrate with editors nicely. >> >> On that last point: >> >> There is still a few things we need to figure out (others on >> gnunet-developers might weigh in here). First of all, how compatible is >> this actually going to be with editing in Emacs and other editors? >> > > I thought I said that in the beginning? Most editors have plugins: > > emacs: > https://llvm.org/svn/llvm-project/cfe/trunk/tools/clang-format/clang-format.el > (n)vim: https://github.com/rhysd/vim-clang-format > vscode: native > sublime: https://packagecontrol.io/packages/Clang%20Format > >> Sure, running an external tool afterwards is always possible, but does >> this integrate with Emacs to the point that the formatting is >> applied/conveniently apply-able during editing? (Say what I do right >> now: press Tab and have the indentation match what clang will do? Or can >> we adjust the existing Emacs style (and other editors!) to match 100% >> what clang formatter generates?) >> >> Naturally, some of the style issues that remain (like the impossibility >> to force a break after function arguments even if the line is short even >> without one) may feed into this. >> >> >> >> > > >
signature.asc
Description: Message signed with OpenPGP
_______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
