Re: Adding support for xref jumping to headers/interfaces

[Eli Zaretskii <eliz@gnu.org>]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 16 May 2023 17:10:40 -0400
> Cc: Eli Zaretskii <eliz@gnu.org>, stephen_leake@stephe-leake.org, john@yates-sheets.org, 
>  	rms@gnu.org, fgunbin@fastmail.fm, casouri@gmail.com, emacs-devel@gnu.org, 
>  	azeng@janestreet.com
> 
> An option I didn't mention originally: Perhaps xref-find-definitions
> could just show both implementation and interface.  That would remove
> the need for any new keybindings.  The UI might be worse but perhaps
> it could be improved.
> 
> This is inspired by this comment:
> https://github.com/joaotavora/eglot/issues/302#issuecomment-534202561
> 
> The relevant excerpt:
> > By the way, on a tangent, I think it's a mistake on LSP's part to
> > import C++/Java's ecosystem of possible symbol loci. In Common Lisp,
> > there are many different types of construct associated with a symbol
> > and they are all "definitions". A good IDE like SLIME will use
> > something akin to xref-find-definitions (indeed xref is modelled after
> > SLIME) and categorize them properly in the result buffer if there is
> > more than one. So the command should have been textDocument/definition
> > with some kind of subtype parameter, or at least this is where xref
> > should evolve to, i.e. xref should keep the single command
> > xref-find-definitions and maybe augment it with some "definition-type"
> > parameter.

IME, in at least some OOP environments, definition and interface are
considered to be very different things.  It is possible that CL is not
one of them (after all, the OOP model of Lisp is quite different from
that of, say, C++ and Java).

So I'm not sure lumping these two together will be welcome by
everyone.  Especially since you seem to suggest that the format of the
*XREF* buffer also be changed to include the indication of which is
which.