[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: making xref.el a core ELPA package
From: |
João Távora |
Subject: |
Re: making xref.el a core ELPA package |
Date: |
Thu, 27 Dec 2018 17:59:27 +0000 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Dmitry Gutov <address@hidden> 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 <address@hidden>
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