Hi Antoine,
It looks like I forgot to send this draft... (Dated 07 Sep 2021). So,
here's an update on the packaging: It's done, but the software seems to
be fundamentally broken by something that I haven't yet been able to
identify. I also confess to low motivation, and to worrying that this
package could become a huge time/energy sink like Elpy...I should
probably share my WIP soon so someone can go "Aha! That this is what
you missed!", and I'm hoping that's all it is, because I'm appalled that
the most basic function (rg) is nonfunctional. Meanwhile, counsel-rg
works perfectly.
--
If you're short on time, skip to "As an aside" for some new info (you've
read the rest on IRC).
Antoine Beaupré <anarcat@debian.org> writes:
>> If you think the process might be interesting content for
>> Debian Planet, please let me know :-)
>
> That would be interesting, for sure, but no pressure. :)
Ok, will do! Casual deadline of mid-October.
>>> I'm not actually sure why Nicholas picked rg.el.
>>
>> I can update this bug with my rationale (from IRC) if you think it would
>> be useful to others.
>
> That, however, seems like an important thing to document here, for
> posterity.
>
Ok, for posterity :-)
Why this source package name? Rg-el, because we can't have src:rg.el,
and the -el suffix denotes elisp; you're totally right, src:rg-el will
produce bin:elpa-rg :-) Finally, ITPs are for source package names, but
I can't remember if this is a rule or convention.
I chose rg.el over alternatives (such as the excellent Deadgrep) for a
variety of reasons. First, based on the README, it seemed to fit what I
think your use case (and criteria for an improved grep) was; second, it
(subjectively) seemed like a more familiar interface (standard Emacs
conventions and expectations), and it has (rg-enable-menu) which uses
Magit's transient.el. The menu mode has a "magit-like" interface, and
UI consistency between modes is part of my overarching goal of making
contributions that make Emacs more accessible and less arcane for new
users; third, it impresses me that rg.el provides a backward-compatible
config key for keybindings when it moved to new, allegedly more
consistent ones ("new is better" is a pet peeve of mine, and I believe
that Emacs projects that have churn in this area would annoy you);
finally, the test suite impresses me, especially how it takes care to
test interoperation with other modes for possible regressions.
Rg.el also seems to be significantly more popular on MELPA, which is
more of a "probability of popularity in Debian" than a quality
thing... (eg: number of people who benefit to hours of work ratio thing)
As an aside, personally I'm happy with counsel-ag, and cousel-rg works
great; I packaged bin:elpa-counsel as part of src:emacs-ivy, which used
to be a hard dependency of elpa-find-file-in-project, which used to be a
dependency of src:elpy, my first big project (and your RFP).
Unfortunately upstream wasn't able to keep pace with Python breaking
changes, Python 3.9 broke Elpy's ERT tests badly.
For a user who doesn't know which to choose, at this point it seems like
this:
Choose rg.el for the traditional Emacs interface or Magit-like interface
Choose Ivy/Counsel for a completion framework that is non-jarring for
long-time Emacs users, and that is fast (in both cases, in when
compared to Helm). In other words, it seems to be a case of UI
preference and inclination due to established habits.
At the moment I'm currently stumped about why "M-x rg" doesn't find
hits/matches that /usr/bin/rg does, even thought the ERT tests indicate
that this codepath is functional and correct. My hypothesis is that
someone made a perfectly reasonable assumption that may have now been
revealed to be a technical deficiency.
Worse case scenario: please ping me in mid-October.
Regards,
Nicholas
Attachment:
signature.asc
Description: PGP signature