* making xref.el a core ELPA package [not found] ` <CALDnm518LTJGu5FNCGRz29EUrnBXJcFN0qy7ixqGVvPSgCxUZA@mail.gmail.com> @ 2018-12-27 1:12 ` Dmitry Gutov 2018-12-27 17:59 ` João Távora 0 siblings, 1 reply; 6+ messages in thread From: Dmitry Gutov @ 2018-12-27 1:12 UTC (permalink / raw) To: João Távora; +Cc: Juri Linkov, emacs-devel 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: making xref.el a core ELPA package 2018-12-27 1:12 ` making xref.el a core ELPA package Dmitry Gutov @ 2018-12-27 17:59 ` João Távora 2018-12-27 20:12 ` Juri Linkov 0 siblings, 1 reply; 6+ messages in thread From: João Távora @ 2018-12-27 17:59 UTC (permalink / raw) To: Dmitry Gutov; +Cc: Juri Linkov, emacs-devel 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: making xref.el a core ELPA package 2018-12-27 17:59 ` João Távora @ 2018-12-27 20:12 ` Juri Linkov 2018-12-27 21:41 ` João Távora 0 siblings, 1 reply; 6+ messages in thread From: Juri Linkov @ 2018-12-27 20:12 UTC (permalink / raw) To: João Távora; +Cc: emacs-devel, Dmitry Gutov > 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. ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: making xref.el a core ELPA package 2018-12-27 20:12 ` Juri Linkov @ 2018-12-27 21:41 ` João Távora 2018-12-28 14:32 ` Stefan Monnier 0 siblings, 1 reply; 6+ messages in thread From: João Távora @ 2018-12-27 21:41 UTC (permalink / raw) To: Juri Linkov; +Cc: emacs-devel, Dmitry Gutov 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: making xref.el a core ELPA package 2018-12-27 21:41 ` João Távora @ 2018-12-28 14:32 ` Stefan Monnier 2018-12-28 16:28 ` João Távora 0 siblings, 1 reply; 6+ messages in thread From: Stefan Monnier @ 2018-12-28 14:32 UTC (permalink / raw) To: emacs-devel >> 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 ^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: making xref.el a core ELPA package 2018-12-28 14:32 ` Stefan Monnier @ 2018-12-28 16:28 ` João Távora 0 siblings, 0 replies; 6+ messages in thread From: João Távora @ 2018-12-28 16:28 UTC (permalink / raw) To: Stefan Monnier; +Cc: emacs-devel [-- 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 --] ^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2018-12-28 16:28 UTC | newest] Thread overview: 6+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- [not found] <87a7ktqqx7.fsf@mail.linkov.net> [not found] ` <9215183d-0a44-88b5-5b3c-d0da31f749ad@yandex.ru> [not found] ` <CALDnm518LTJGu5FNCGRz29EUrnBXJcFN0qy7ixqGVvPSgCxUZA@mail.gmail.com> 2018-12-27 1:12 ` making xref.el a core ELPA package Dmitry Gutov 2018-12-27 17:59 ` João Távora 2018-12-27 20:12 ` Juri Linkov 2018-12-27 21:41 ` João Távora 2018-12-28 14:32 ` Stefan Monnier 2018-12-28 16:28 ` João Távora
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).