making xref.el a core ELPA package

making xref.el a core ELPA package

[Dmitry Gutov]

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.

 > I can see some advantages...

Do you have anything specific in mind? Aside from simply getting new 
features to the users faster.

Re: making xref.el a core ELPA package

[João Távora]

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

Re: making xref.el a core ELPA package

[Juri Linkov]

> 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.

It's a big surprise to me that xref is a standalone package.
I thought it's simply a better replacement of the old find-tag.

> Either:
>
> * we revert this (I believe we shouldn't)
> * we use some indirection that is a no-op in 26.1

Sure, you could add some conditionals to support older versions.

Re: making xref.el a core ELPA package

[João Távora]

Juri Linkov <juri@linkov.net> writes:

>> 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.
>
> It's a big surprise to me that xref is a standalone package.

There is a misunderstanding here.  It's not, but I am proposing that it
become a semi-standlone pacakge.

> I thought it's simply a better replacement of the old find-tag.

It is.

>> Either:
>>
>> * we revert this (I believe we shouldn't)
>> * we use some indirection that is a no-op in 26.1
>
> Sure, you could add some conditionals to support older versions.

It's kinda lame to do this in a file that is in Emacs core, but if the
others accept and it's a one-time well-documented thing, fine by be.  A
proper indirection (hook/function variable) would be better, but not
really justified by this one use case.

João

Re: making xref.el a core ELPA package

[Stefan Monnier]

>> Sure, you could add some conditionals to support older versions.

Very much so.

> It's kinda lame to do this in a file that is in Emacs core,

We have lots of that in Emacs's own files, since many of Emacs's
packages are also distributed outside (e.g. cc-mode, Tramp, ...).
It's not lame,


        Stefan

Re: making xref.el a core ELPA package

[João Távora]

[-- Attachment #1: Type: text/plain, Size: 454 bytes --]

On Fri, Dec 28, 2018 at 2:35 PM Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> >> Sure, you could add some conditionals to support older versions.
> > It's kinda lame to do this in a file that is in Emacs core,
> It's not lame,


Erm, you realize this is version control with in-code
conditionals... I'm fine with it, really, I don' have any better
alternatives, but let's call the bulls by the names, as they say
back home :-)

João

[-- Attachment #2: Type: text/html, Size: 802 bytes --]