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

[Ergus <spacibba@aol.com>]

Hi Jim:

On February 4, 2023 8:44:12 PM GMT+01:00, Jim Porter <jporterbugs@gmail.com> wrote:
>(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?
>

Eli?

>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 have exactly the same issue... So I am happy to know that the tramp compatibility is tested :). BTW, in the gtags-mode package I added a search strategy with connection local variables and some caching that is reasonable to avoid using executable-find excessively with tramp, but also minimizing the manual user customization. 

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

IMHO I would prefer a simpler version which only implements the new basic features (functions) or improves the ones in the emacs core (do one thing and do it right). Mainly to minimize external dependencies, potential conflicts and the danger of depending on something that may get unmaintained/broken in a while (simple is better than complex). All improves for other packages can be added as optional (different packages, or advises/hooks that the user can add easily to its config, so they only need a couple of lines in the readme... Like vertico does...

WDYT?

Best, Ergus.


-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.