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: ng0
Subject: Re: [GNUnet-developers] clang formatting discussion
Date: Thu, 18 Apr 2019 09:20:11 +0000

Schanzenbach, Martin transcribed 4.7K bytes:
> 
> 
> > On 18. Apr 2019, at 10:50, address@hidden wrote:
> > 
> > Schanzenbach, Martin transcribed 4.5K bytes:
> >> 
> >> 
> >>> 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
> > 
> > We can include an ASL2.0 (Apache-2.0 WITH LLVM-exception) file
> > in contrib right? As far as I remember asl2.0 is compatible to
> > newer gpl.
> > There's a diff reformater for clang-format.
> 
> Not sure I follow. The clang-format config has an implicit license?

No, this is a different subject. clang-format-diff is a python script.
I lost the original URL (somewhere in LLVM), here it is in my repo:
https://c.n0.is/f/util/artifact/aa26f824062e999c
 
> > 
> >>> 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.
> >>> 
> >>> 
> >>> 
> >>> 
> >> 
> > 
> > 
> > 
> >> _______________________________________________
> >> GNUnet-developers mailing list
> >> address@hidden
> >> https://lists.gnu.org/mailman/listinfo/gnunet-developers
> 


Attachment: signature.asc
Description: PGP signature


reply via email to

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