A note about clang-format

A note about clang-format

[Gerd Möllmann]

FYI, maybe it's helpful

// clang-format off
// clang-format on

can be used to keep clang-format from touching regions of code, also
when used via Eglot + clangd.  Works for me.

Re: A note about clang-format

[Corwin Brust]

Thank you Gerd!

On Tue, Aug 22, 2023 at 9:55 AM Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
> FYI, maybe it's helpful

Definitely helpful.

>
> // clang-format off
> // clang-format on
>
> can be used to keep clang-format from touching regions of code, also
> when used via Eglot + clangd.  Works for me.
>

A user was on IRC asking how to "stopping Elgot from messing with my
C++", just minutes after I received your email.   Surrounding the code
with these comments solved the issue.  In any event, I wanted to let
you know this definitely helped at least one person already; I've
included Sacha in BCC in case this may be of interest for EmacsNews.

Re: A note about clang-format

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 783 bytes --]

On Tue, Aug 22, 2023, 19:29 Corwin Brust <corwin@bru.st> wrote:

>
> > FYI, maybe it's helpful
>
> Definitely helpful.
>
> A user was on IRC asking how to "stopping Elgot from messing with my
> C++", just minutes after I received your email.   Surrounding the code
> with these comments solved the issue.  In any event, I wanted to let
> you know this definitely helped at least one person already; I've
> included Sacha in BCC in case this may be of interest for EmacsNews.
>

Yep, definitely helpful. That user might also be interested in knowing that
the reason that Eglot is so eager to reformat on type is because the server
eagerly provides that capability itself.

But it can be ignored via 'eglot-ignored-server-capabilities', which see.

João



>

[-- Attachment #2: Type: text/html, Size: 1444 bytes --]

Re: A note about clang-format

[Gerd Möllmann]

João Távora <joaotavora@gmail.com> writes:

> But it can be ignored via 'eglot-ignored-server-capabilities', which see.

Actually, I found that auto-formatting quite nice when I switched from
lsp-mode to eglot today, so I didn't want to suppress this.  But the
DEFUNs in Emacs' C code are something from another world.  I don't know
if any formatter can cope with them.

Might be good to start using this in the Emacs sources, too, if that's
ok.  The existence of a .clang-format makes me think some users might
appreciate it.

Re: A note about clang-format

[Gerd Möllmann]

On 22.08.23 20:29, Corwin Brust wrote:
> Thank you Gerd!

👍

Re: A note about clang-format

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 913 bytes --]

On Tue, Aug 22, 2023, 19:59 Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

> João Távora <joaotavora@gmail.com> writes:
>
> > But it can be ignored via 'eglot-ignored-server-capabilities', which see.
>
> Actually, I found that auto-formatting quite nice when I switched from
> lsp-mode to eglot today, so I didn't want to suppress this.  But the
> DEFUNs in Emacs' C code are something from another world.  I don't know
> if any formatter can cope with them.
>
> Might be good to start using this in the Emacs sources, too, if that's
> ok.  The existence of a .clang-format makes me think some users might
> appreciate it.
>

I think we (meaning you) should lobby Eli for compile_commands.json
generation first :)

M-x eglot in Emacs sources still doesn't work oob and there's little reason
for that (well, apart from some understandable llvm aversion, but there are
other servers...).

[-- Attachment #2: Type: text/html, Size: 1478 bytes --]

Re: A note about clang-format

[Gerd Möllmann]

João Távora <joaotavora@gmail.com> writes:

> I think we (meaning you) should lobby Eli for compile_commands.json
> generation first :)

I think that might not even be necessary because users can do that
easily, if they know how.  See https://github.com/rizsotto/Bear, for
example, which is GPLv3.  With it, do an initial full build with "bear
-- gmake" instead of just "gmake".

Re: A note about clang-format

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 1532 bytes --]

On Tue, Aug 22, 2023, 20:45 Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

> I think we (meaning you) should lobby Eli for compile_commands.json
> > generation first :)
>
> I think that might not even be necessary because users can do that
> easily, if they know how.  See https://github.com/rizsotto/Bear, for
> example, which is GPLv3.  With it, do an initial full build with "bear
> -- gmake" instead of just "gmake".
>

Yes, I've used 'bear' before (in fact I asked you, remember?).

But -- great as it is -- it's still basically a hack which requires
actually compiling the code to learn _how_ it would be compiled. That's not
always practical, perhaps not even always possible depending on the
toolchain to use.

So it's a needless hindrance and, afair, not perfectly accurate (you had
some non-trivial ad-hoc tweak script as I recall).

I don't see a fundamental technical reason not to generate this simple file
from our own configuration script, which is the source of truth for this
information after all.  In all Cmake projects I work with, it's a matter of
setting a simple variable. I wonder if the automake world doesn't have
something similar. If it doesn't, how hard can it be to add one?

We should lower that bar so that every Emacs C hacker (including Eli and
other long timers) can benefit from LSP (with Eglot, of course ;) ). This
will be beneficial to Emacs C code and to Eglot itself of course.

And with that, it seems I have done all the lobbying myself :)

João

>

[-- Attachment #2: Type: text/html, Size: 2556 bytes --]

Re: A note about clang-format

[Eli Zaretskii]

> From: João Távora <joaotavora@gmail.com>
> Date: Tue, 22 Aug 2023 20:07:32 +0100
> Cc: Corwin Brust <corwin@bru.st>, emacs-devel <emacs-devel@gnu.org>
> 
> M-x eglot in Emacs sources still doesn't work oob and there's little reason for that (well, apart from
> some understandable llvm aversion, but there are other servers...).

There's no server based on GCC, AFAIK.  I asked GCC developers to work
on that, and they all agreed it's a good development direction, but
nothing practical came out of it, AFAICT.

Re: A note about clang-format

[Gerd Möllmann]

João Távora <joaotavora@gmail.com> writes:

> On Tue, Aug 22, 2023, 20:45 Gerd Möllmann <gerd.moellmann@gmail.com> wrote:
>
>  > I think we (meaning you) should lobby Eli for compile_commands.json
>  > generation first :)
>
>  I think that might not even be necessary because users can do that
>  easily, if they know how.  See https://github.com/rizsotto/Bear, for
>  example, which is GPLv3.  With it, do an initial full build with "bear
>  -- gmake" instead of just "gmake".
>
> Yes, I've used 'bear' before (in fact I asked you, remember?).

Sorry, I didn't remember that that was you :-).

>
> But -- great as it is -- it's still basically a hack which requires
> actually compiling the code to learn _how_ it would be
> compiled. That's not always practical, perhaps not even always
> possible depending on the toolchain to use.

Some alternatives to Bear use a --dry-run.  I haven't tried them though:
https://github.com/nickdiego/compiledb for example.  Would that be
sufficient for the cases you think of?

> So it's a needless hindrance and, afair, not perfectly accurate (you
> had some non-trivial ad-hoc tweak script as I recall).

Yes, the script adds an "-include config.h" for the files in src/.  That
makes things a little bit smoother with clangd.  One can do without,
though.

> I don't see a fundamental technical reason not to generate this simple
> file from our own configuration script, which is the source of truth
> for this information after all.  In all Cmake projects I work with,
> it's a matter of setting a simple variable. I wonder if the automake
> world doesn't have something similar. If it doesn't, how hard can it
> be to add one?

AFAIK, there is nothing like that in autoconf/automake.  At least last
time I checked about a year ago there wasn't.  I also have a vague
memory that someone on their mailing list said it it would be
impoossible to produce a correct compilation database without running
make, because one could alwasys do something like "CFLAGS=... make".
Can't find that article ATM, maybe I'm confusing that with something
else.