Schanzenbach, Martin transcribed 6.4K bytes: > > > > On 15. Apr 2019, at 12:24, Christian Grothoff <groth...@gnunet.org> wrote: > > > > Signed PGP part > > Dear all, > > > > First of all, I like Martin's initiative as any attempt at trying to > > improve the situation is very welcome. Hartmut is of course right that > > it should be discussed, but I think committing the files first so we > > have a good basis for discussion was also the right move. It's not like > > Martin reindented the entire project already ;-). So please no drama on > > this, there is really not even a conflict. > > > > I have a few options that -- based on reading only the documentation and > > not yet trying it out on actual code -- I would set differently (diff > > attached for discussion). > > > > I worry a bit that applying an auto-formatter will inherently destroy > > particularly neat formatting, i.e. > > > > fun (key, value, > > key2, value2, > > key3, value3) > > > > is likely going to end up with > > > > fun (key, > > value, > > key2, > > value2); > > > > as there is simply no way of teaching such exceptions to the > > auto-formatter. OTOH, having this done in a consistent way will also > > avoid a lot of stupid reindentation commit work, so the trade-off might > > be worth it. > > I don't think clang-format can do that as this semantic is not generalizable. > But, I also think this is not something an editor config can achieve so we > could just disable auto indent of function parameters in the clang-format. > > > > > Now, *if* this actually works acceptably (I have not tested it), we > > would want to have it in the emacs configuration, but also as a local > > hook for Git (auto-format before commit?), plus as a hard check on the > > server (is it indented? no? go away!). > > clang-format is a CLI tool. So I assume this is trivial.
Should be doable, yes. I have a tool which uses clang-format to make obfuscated C code readable according to clang standards.. so if this works, anything is possible. > > > > Anyway, that's not today, for now I would just encourage everyone to > > play with Martin's suggestion, propose adjustments to the style (see my > > attached diff) and report code that ends up formatted "badly" here to > > see if we 'dare' to automate and enforce this. > > Yep! If sb does not want to use it _in_ the editor, the clang-format tool can > still be used in a "make check-syntax" or even better a git hook as you > propose. > > > > > Happy hacking! > > > > Christian > > > > On 4/15/19 11:35 AM, Florian Dold wrote: > >> Hi Hartmut, > >> > >> It's a bit disheartening to see an honest attempt to improve things > >> being shot down like this. > >> > >> The clang-format style that Martin created tries to mirror what style > >> the existing codebase already has or is supposed to have. If you want > >> to make any tweaks on top of that, please contribute them or voice your > >> criticism constructively! > >> > >> GNUnet isn't completely following the GNU Coding Standards anyway, is it? > >> > >> And to suggest that everybody should use Emacs to format code is > >> outright ridiculous. Unlike clang-format, it does not integrate into > >> other editors (yes, those do exist!), and it sucks badly at formatting > >> code. It only does indentation. Well, unless your lines are too long. > >> > >> GNUnet is rife with "char * foo;", weirdly formatted macros and overly > >> long lines. Emacs won't fix those. > >> > >> Please also think of people (students!) that don't have your exact setup > >> and want to contribute to GNUnet without having to use Emacs, and > >> without somebody having to do manual code review for code style. At > >> least Guix has some helper script that formats the code using Emacs > >> under the hood, without having to know Emacs! > >> > >> - Florian > >> > >> On 4/15/19 10:53 AM, Hartmut Goebel wrote: > >>> Am 15.04.19 um 10:02 schrieb Schanzenbach, Martin: > >>>> FYI I added a clang-format at "contrib/conf/editors/clang-format". > >>> > >>> I'm curious about this, since the development guide says: "We follow the > >>> GNU Coding Standards (see The GNU Coding Standards > >>> <https://www.gnu.org/prep/standards/standards.html#Top> in The GNU > >>> Coding Standards). > >>> > >>> Beside this: If you switch to clang coding style, please adjust > >>> .dir-locals.el to pull in the correct settings and make sure this is > >>> available in all of our repos. See > >>> https://lists.gnu.org/archive/html/gnunet-developers/2019-03/msg00055.html > >>> > >>> Also I'm curious about you adding this to the code first and then > >>> discussion the topic. If we decide *not* to change the coding style, we > >>> will have dead artifacts trashing all developers repos for years. > >>> > >> > >> _______________________________________________ > >> GNUnet-developers mailing list > >> GNUnet-developers@gnu.org > >> https://lists.gnu.org/mailman/listinfo/gnunet-developers > >> > > <delta.diff> > > > > > > _______________________________________________ > GNUnet-developers mailing list > GNUnet-developers@gnu.org > https://lists.gnu.org/mailman/listinfo/gnunet-developers _______________________________________________ GNUnet-developers mailing list GNUnet-developers@gnu.org https://lists.gnu.org/mailman/listinfo/gnunet-developers
