Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1077049 > unrolled thread

Bug#993370: RFP: rg-el -- elpa-rg

Back to article view | Back to linux.debian.bugs.dist

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Bug#993370: RFP: rg-el -- elpa-rg Nicholas D Steeves <sten@debian.org> - 2021-10-21 01:10 +0200
    Bug#993370: RFP: rg-el -- elpa-rg Antoine Beaupré <anarcat@debian.org> - 2021-10-21 02:20 +0200
      Bug#993370: RFP: rg-el -- elpa-rg Nicholas D Steeves <sten@debian.org> - 2021-10-28 04:40 +0200
      Bug#993370: RFP: rg-el -- elpa-rg Nicholas D Steeves <sten@debian.org> - 2021-10-28 05:10 +0200

#1077049 — Bug#993370: RFP: rg-el -- elpa-rg

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [next] | [standalone]

#1077057

On 2021-10-20 18:58:03, Nicholas D. Steeves wrote:

[...]

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

[...]

Thanks for the update! That's interesting! I've been meaning to look at
other completion frameworks, I keep getting confused because I can't
even remember which one I'm using.

For the record, I'm probably going to switch away from elpy towards the
more standard lsp-mode, which covers more languages and actually works
with Python (and other tools like mypy/pyright). I'm sorry you had to
work so hard on this package only to see it miss bullseye and end up in
that state. But I guess that's the life of software: a few of my own
personal projects didn't make it to bullseye due to bitrot and I was
also sad about that...

I am not sure we should continue with rg-el. Maybe deadgrep or
counsel-rg are better paths forward?

Thanks again!

a.

-- 
La démocratie réelle se définit d'abord et avant tout par la
participation massive des citoyens à la gestion des affaires de la cité.
Elle est directe et participative. Elle trouve son expression la plus
authentique dans l'assemblée populaire et le dialogue permanent sur
l'organisation de la vie en commun.  - De la servitude moderne

[toc] | [prev] | [next] | [standalone]

#1078318

[Multipart message — attachments visible in raw view] — view raw

Antoine Beaupré <anarcat@debian.org> writes:

> On 2021-10-20 18:58:03, Nicholas D. Steeves wrote:
[snip]
> Thanks for the update! That's interesting! I've been meaning to look at
> other completion frameworks, I keep getting confused because I can't
> even remember which one I'm using.

I think it might have been the built-in ido mode, if you're using one at
all--IIRC you weren't using one last we discussed our Emacs configs and preferences.

> For the record, I'm probably going to switch away from elpy towards the
> more standard lsp-mode, which covers more languages and actually works
> with Python (and other tools like mypy/pyright).

That's totally reasonable, and in fact in upstream Elpy issue tracker
there was a discussion about whether the future of Elpy would be an
extension to lsp-mode.

> I'm sorry you had to work so hard on this package only to see it miss
> bullseye and end up in that state. But I guess that's the life of
> software: a few of my own personal projects didn't make it to bullseye
> due to bitrot and I was also sad about that...

It's ok, I learned a lot on the way, and never would have discovered
find-file-in-project and Ivy/Counsel/Swiper.  I hear you!  So much work
is keeping up with all the breaking changes...  Elpy had a bit of a
crisis when Jorgen Schaefer retired, Gaby Launay carried the banner, but
then RSI got him :-(  If you want to send a message of
support/solidarity, his email's in the control file.

> I am not sure we should continue with rg-el. Maybe deadgrep or
> counsel-rg are better paths forward?
>

Quite possibly yes.  That said, I *really* don't like the feeling of
being beaten, so I took a crack at it today, and I think the cause of
the total dysfunction of rg-el might actually be a bug in our ripgrep.
I'll send a follow up email momentarily that CCs the maintainers.

> Thanks again!
>

You're very welcome :-)

> a.
>
> -- 
> La démocratie réelle se définit d'abord et avant tout par la
> participation massive des citoyens à la gestion des affaires de la cité.
> Elle est directe et participative. Elle trouve son expression la plus
> authentique dans l'assemblée populaire et le dialogue permanent sur
> l'organisation de la vie en commun.  - De la servitude moderne

Je suis d'accord, la démocratie directe est l'idéal, mais pendant mes
cours de science politique j'ai appris comment il y a un scaling problem
insurmontable quand le cadre dépasse une certaine population :-/

Cheers,
Nicholas

[toc] | [prev] | [next] | [standalone]

#1078320

[Multipart message — attachments visible in raw view] — view raw

As promised, here's what I found while debugging:

    "rg --type=all foo" appears to be broken
    https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=997974

Cheers,
Nicholas

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web