Re: [RFC] Urgrep: New ELPA submission (eventually)

[Jim Porter]

(Coincidentally, I was actually thinking about posting a followup to 
this thread this weekend myself!)

On 2/4/2023 9:12 AM, Ergus wrote:
> Any progress on this? I have seen the package on github and it looks
> very nice... but sadly not in elpa yet, so it won't be in my system
> since then.
>
> Is there something missing?

Mostly a lack of time, and trying to spend the Emacs time I do have on 
fixing some Eshell stuff. But since any future Eshell changes will be in 
Emacs 30, the time pressure is off there.

I do have a couple of open questions that I couldn't find answers for 
though:

First, assigning copyright of Urgrep to the FSF (so that it can go in 
GNU ELPA) is just a matter of updating the copyright field in the code, 
right? Do I need to fill out any paperwork or anything too?

Second, my usual process for versioning is that I'll release a version 
like "1.0" by updating the "Version:" field and tagging it. Then, in the 
next commit, I update the "Version:" field to something like 
"2.0-snapshot". So in this case, I'd expect GNU ELPA to give users 
version 1.0, and GNU ELPA-devel to give users the latest 2.0-snapshot 
version. Does ELPA understand that? I see that after cutting a release, 
lots of Emacs packages just leave the version identifier alone until the 
next release. I'd prefer not to do that, just in case someone reports a 
bug on the snapshot version: having a different version string for the 
snapshot helps to prevent confusion about which version they're using.

I think GNU ELPA-devel solves this confusion by appending the date to 
the version identifier (so you get something like 1.0.20230204...), but 
that wouldn't help users pulling Urgrep directly from Git.

> I would like even to see this package or similar approach in vanilla
> (mainly to speedup the venerable rgrep which sadly gets too slow on
> big projects due to the serialization that find adds to grep.)
There are definitely a number of places that core Emacs would benefit 
from something like this. For example, Xref does some of this on its 
own, but has fewer options for search programs, and I'm not sure if 
Xref's search program is remote-connection aware (one of my main reasons 
for writing Urgrep is that I use Tramp extensively, and not every system 
I connect to has my favorite search program).

I could see Urgrep becoming a core Emacs package once it's had wide 
enough use that all the major bugs/design flaws have been worked out. 
That might require shuffling some things around though, since Urgrep 
comes with hooks for wgrep, but wgrep is currently in Non-GNU ELPA. I'm 
not sure it's ok for something in Emacs proper to have an optional 
dependency on a Non-GNU package.