Re: Adding support for xref jumping to headers/interfaces

[João Távora]

On Mon, Nov 13, 2023 at 1:03 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
>
> On 12/11/2023 04:25, João Távora wrote:
> > On Sun, Nov 12, 2023 at 2:10 AM Dmitry Gutov <dmitry@gutov.dev> wrote:
> >>
> >> On 12/11/2023 04:08, João Távora wrote:
> >>> Noooo.  Eglot only does LSP things!
> >>
> >> Server-specific extensions are LSP things, in my book. Okay, it might
> >> not be in eglot.el itself, but then someone will create
> >> eglot-superduperclang.el to support those extensions.
> >
> > Could be, but why can't this code live in c++-ts-mode?
>
> What about c++-mode users? Or the devoted sm-c-mode aficionados?

Happy to put it an a superduperclang.el file required by both of
them.  I have my doubts Alan would like that, it took too much
discussion just to convince him to set a flymake variable some years
ago.

> And it would be odd if c++-ts-mode would only function as expected
> together with Eglot -- at the very least, it will be a challenge to
> explain this to the users.

It would function OK without it.  Just as it does now.  Just no
cross-referencing support.  Much like python.el works without a
python interpreter, but better with it.

> >>> The major mode may do that if
> >>> it has another alternative backend, or if it knows it is using LSP
> >>> with a specific language server, like 'superduperclangdfork'.
> >>
> >> I'm pretty sure major modes that are specific to the language server in
> >> use are a bad idea.
> >
> > You may have misunderstood my suggestion.
> >
> > I'm saying code specific to certain languages, LSP-based on not,
> > should always live in major mode files and have major-mode prefixes.
>
> We're not just talking about features specific to a language, but
> features specific to a certain potential future version of a language
> server, which might or might not be available through a certain LSP
> client/Xref backend, someday.
>
> Otherwise we could just add those commands now, right?
>
> Aside from the issue of multiple major modes existing for a number of
> important languages.
>
> > It's always been like this.  The LSP server program doesn't have
> > to be available for themajor mode to work, but it works better
> > with it.
>
> And the "...but it works better with it" has often been expressed in
> terms of minor modes. E.g. SLIME/Sly/CIDER/lots of others.

Yes, you can use an extra minor mode if you want or not.  But
Eglot by itself is not that minor mode.

> Etags might be put into that category too (you have to build tags first
> to use it) -- and all of its language-specific concerns (how to build
> tags, for example? which flags are preferred) never found its way its
> major modes.
>
> > Major modes already do this.  For example, you don't _have_ to
> > have a Python interpreter program to use python-mode.el to edit
> > Python code,  but having one enables M-x run-python of course.
> > And run-python uses comint.el which is a library that python.el
> > relies on.
>
> The Python interpreter always came pre-installed with Python.

Yes, but you don't have to install Python to edit python code in
Emacs, do you?

> Anyway... this was a digression that's probably not important for now.
> Whether the new advanced commands are defined in Eglot or in major
> modes, should have no bearing on what we do now, or whether we add a new
> set of "common" commands to xref.el.

I think it does, because the new advanced commands may become just as
popular or more as what you say as "common" commands.  This is the
"slippery slope" part of my argument.  The other part of my argument
is that the "common" commands you want to import from LSP isn't really
that great and that you don't _need_ to, because major modes.

Also I think that this particular decision doesn't need to be taken
now.  Whichever way we go, it won't invalidate what's in the Git
branch right now.

João