Re: [GNUnet-developers] clang formatting discussion

[ng0]

Christian Grothoff transcribed 7.2K bytes:
> On 4/17/19 11:25 PM, Schanzenbach, Martin wrote:
> >> 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
> > 
> 
> Yes, the question is this: are there any developers here where their
> editor cannot be reasonably integrated with clang-format? If so, please
> do shout out now!

Hi.
I can't get clang-mode from LLVM to work. But I guess I should look into
picking the correct version instead of 'head' from svn. Assuming the
clang-format file we have added is not for clang 8 (unreleased) but for
clang-7.0.1

But I see you've pointed out everything I need to know in the rest of
this email.
 
> I've so far heard only positive feedback for Martin's overall initiative
> to get indentation under control, so for now I'll proceed with the
> assumption that there are no blockers. But if you do have an issue with
> this, please do let me know (on or off list) as soon as possible. If
> there are no (sound) objections soon, I will give ng0/schanzen the
> go-ahead to enable enforcement of clang formatting for all Git commits
> in the future!
> 
> Anyway, aside from the general policy debate, please read on for more
> specific related issues.
> 
> //// Deployment experience
> 
> I had to install clang-format-9 from Debian experimental, as our
> configuration includes options that are only in v9.
> 
> For Emacs user's reference: Without v9, the Emacs integration silently
> failed. I also had to create a symlink from clang-format to
> clang-format-9, as the Emacs integration only looks for the clang-format
> binary (and otherwise also fails silently).
> 
> 
> Other than that, Emacs integration was straightforward:
> 
> I added to gnunet/.dir-locals.el a hook on save (this may end up in Git
> "soon")
> 
> >>>
> ((c-mode
>   (eval add-hook 'before-save-hook #'clang-format-buffer nil t)))
> <<<
> 
> 
> and to .emacs the logic to find the clang-format package
> 
> >>>
> (require 'package)
> (add-to-list 'package-archives '("melpa" . "https://melpa.org/packages/";))
> ;; initialize package system
> (package-initialize)
> ;; actually load the package
> (require 'clang-format)
> <<<
> 
> And of course also installed the clang-format package (interactively,
> M-x install-package) as per documentation from Martin's first link above.
> 
> Finally, the clang-format style symlink must be set:
> 
> # Install clang format symlink
> ln -s contrib/conf/editors/clang-format .clang-format
> 
> (this I will at to the bootstrap script).
> 
> 
> //// Formatting gripes
> 
> My remaining main issue with
> https://clang.llvm.org/docs/ClangFormatStyleOptions.html
> is that it cannot currently be forced to put a break after each argument
> and each parameter, and it also cannot detect the exception that a
> function has key-value pairs and thus should keep the arguments paired.
> 
> However, the latter case is solvable! If we have key-value pairs, we can do:
> 
> /* clang-format off */
> fun (generalargs,
>      key1, value1,
>      key2, value2,
>      key3, value3);
> /* clang-format on */
> 
> Real-world example from gnunet-gtk/src/namestore/gnunet-namestore-gtk.c:
> 
>  /* clang-format off */
>  gtk_tree_model_get (tm, &iter,
>                      GNS_TREESTORE_COL_RECORD_TYPE, &n_type,
>                      GNS_TREESTORE_COL_IS_PUBLIC, &n_public,
>                      GNS_TREESTORE_COL_EXP_TIME, &n_exp_time,
>                      GNS_TREESTORE_COL_EXP_TIME_IS_REL, &n_is_relative,
>                      GNS_TREESTORE_COL_IS_SHADOW, &n_is_shadow,
>                      GNS_TREESTORE_COL_VAL_AS_STR, &n_value,
>                      -1);
>  /* clang-format on */
> 
> That way, clang-format won't touch the *nice* formatting. So if there is
> a very strong reason, I would definitively approve turning off clang for
> parts of the source.
> 
> For this reason, please do NOT simply apply clang-format globally to
> GNUnet.  Instead, when editing a file, do a quick check to see if
> clang-format would destroy something that's just done "right", and *turn
> it off* for those regions.  After that, a single commit with just the
> clang-forward should be OK.
> 
> 
> Happy hacking!
> 
> Christian
> 




> _______________________________________________
> GNUnet-developers mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/gnunet-developers

signature.asc
Description: PGP signature