unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: "João Távora" <joaotavora@gmail.com>
To: Dmitry Gutov <dmitry@gutov.dev>
Cc: Eli Zaretskii <eliz@gnu.org>,
	70408@debbugs.gnu.org, Ergus <spacibba@aol.com>
Subject: bug#70408: 30.0.50; Eglot and Project integration
Date: Sat, 20 Apr 2024 14:10:53 +0100	[thread overview]
Message-ID: <CALDnm51indorYkEWWkT=gNy=+WynmS+rn78UTF5QHG_smuKCwg@mail.gmail.com> (raw)
In-Reply-To: <51785013-d847-4a1d-a5df-3b25dcf1084c@gutov.dev>

On Sat, Apr 20, 2024 at 12:28 PM Dmitry Gutov <dmitry@gutov.dev> wrote:

> > Because of this, C++ projects usually have sth like:
> >
> >    ln -sf build/compile_commands.json compile_commands.json
> >
> > as a build step.
>
> Would you say it's common across most projects? E.g. generated as a
> build step by CMake in out-of-tree comfigurations.
> Or is it something Emacs users tend to add.

Pretty common, yes.  I googled for the ln string:

https://pspdfkit.com/blog/2019/visual-studio-code-for-cpp/  VSCode
https://blog.justforlxz.com/2020/12/23/ccls/  Nvim, I think
https://stackoverflow.com/questions/62461375/clang-using-cmake-to-build-a-compile-commands-json-for-my-project
https://www.reddit.com/r/cmake/comments/u0ztoq/compile_commandsjson_from_cmakelist/
https://clang.llvm.org/docs/HowToSetupToolingForLLVM.html

Then there is this youtube video I happened to catch recently.

https://www.youtube.com/watch?v=nRpvWgymOuc&t=2467s  7:30

But I guess you can make major modes (or user code) or minor-modes
set eglot-server-programs or add methods to
eglot-initialization-options in clever ways to automatically
point clangd to a given compile-commands.json.  And quite likely
you can convince CMake to create it in other places too.  But
I've never needed to, the 'ln' solution is too good.  You can even
commit the symlink.

> What I'm wondering is whether we might be currently disadvantaged
> compared to the users of some other editors, which might have some more
> auto-detection in that area.

Dunno.  At $DAYJOB there are people struggling in VSCode extension
mayhem with faulty static analysis because they have no idea
that the compile_commands.json is a config-time artifact, maybe
the plugin tries to hide that from them?

But I wouldn't be surprised if lsp-mode features this in its
c++-specific file.  Haven't checked.  My policy has always been to keep
language-specific cruft like this out of Eglot, make the common case
easy and allow the fancy case to be coded in .emacs, in major-mode or
libraries.

> I'm open to continuing this discussion somewhere

Don't bother :-) I've given all my feedback on that matter, don't
have time, am happy with my .emacs hacks and so are those Eglot users.





  reply	other threads:[~2024-04-20 13:10 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <87o7aas3sk.fsf.ref@aol.com>
2024-04-15 21:40 ` bug#70408: 30.0.50; Eglot and Project integration Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-16 11:42   ` Eli Zaretskii
2024-04-16 12:33     ` João Távora
2024-04-16 12:55       ` Dmitry Gutov
2024-04-16 13:51         ` João Távora
2024-04-16 16:02           ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-16 20:30             ` João Távora
2024-04-16 21:51               ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-20 11:28           ` Dmitry Gutov
2024-04-20 13:10             ` João Távora [this message]
2024-04-16 13:03       ` Ergus via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-04-16 16:36       ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CALDnm51indorYkEWWkT=gNy=+WynmS+rn78UTF5QHG_smuKCwg@mail.gmail.com' \
    --to=joaotavora@gmail.com \
    --cc=70408@debbugs.gnu.org \
    --cc=dmitry@gutov.dev \
    --cc=eliz@gnu.org \
    --cc=spacibba@aol.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).