gnunet-developers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [GNUnet-developers] clang formatting discussion


From: Schanzenbach, Martin
Subject: Re: [GNUnet-developers] clang formatting discussion
Date: Thu, 18 Apr 2019 10:59:43 +0200

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 <address@hidden> wrote:
> 
> Signed PGP part
> 
> 
>> On 17. Apr 2019, at 21:08, Christian Grothoff <address@hidden> 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.
>> 
>> 
>> 
>> 
> 
> 
> 

Attachment: signature.asc
Description: Message signed with OpenPGP


reply via email to

[Prev in Thread] Current Thread [Next in Thread]