Re: making xref.el a core ELPA package

["João Távora" <joaotavora@gmail.com>]

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 26.12.2018 16:48, João Távora wrote:
>> However here's a tangent that might affect the decision.
>> Is there any impediment to making xref.el a core ELPA
>> package?
>
> It *might* be as easy as adding the Version and Package-Requires tags
> and then adding a :core entry to elpa/externals-list.
>
> Especially if you volunteer to test it in the previous release(es). We
> definitely need cl-generic, though. So anything older than 26.1 is
> out.

Unfortunately, I just tested with 26.1 and no go.  It doesn't have
next-error-found :-(  This is the commit:

    commit 0c9e3df3c2088b61feb4b4e00d24419459962273
    Author: Juri Linkov <juri@linkov.net>
    Date:   Tue Apr 17 22:27:48 2018 +0300
     
        Use next-error-found to set next-error-last-buffer.

Either:

* we revert this (I believe we shouldn't)
* we use some indirection that is a no-op in 26.1
* we give up the idea

>> I can see some advantages...
>
> Do you have anything specific in mind? Aside from simply getting new
> features to the users faster.

That would be it mostly :-)

xref is a very important dependency of the Eglot LSP client, which could
make it into core Emacs (and remain in ELPA as a :core package).  There
are some issues in Eglot that suggest new features could be useful:

* https://github.com/joaotavora/eglot/issues/77
* https://github.com/joaotavora/eglot/issues/147
* https://github.com/joaotavora/eglot/issues/76

Also, I would like to see a pluggable API to control the insertion of
xrefs into the *xref* buffer.  Not only for LSP but also for SLY (a fork
of SLIME where xref.el originated).

João