Processed: Re: Bug#993370: RFP: rg-el -- elpa-rg
Processing control commands: > retitle -1 RFP: rg-el -- elpa-rg Bug #993370 [wnpp] ITP: rg-el -- elpa-rg: search tool for Emacs based on Ripgrep Changed Bug title to 'RFP: rg-el -- elpa-rg' from 'ITP: rg-el -- elpa-rg: search tool for Emacs based on Ripgrep'. > noowner -1 Bug #993370 [wnpp] RFP: rg-el -- elpa-rg Removed annotation that Bug was owned by Nicholas D Steeves . -- 993370: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993370 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#993370: RFP: rg-el -- elpa-rg
Control: retitle -1 RFP: rg-el -- elpa-rg Control: noowner -1 It doesn't look like #997974 is going to be solved anytime soon, so I'm converting this bug to an RFP to signal that anyone who wants to work on this bug, and to pursue resolution of #997974 is welcome to do so. Cheers, Nicholas signature.asc Description: PGP signature
Bug#993370: RFP: rg-el -- elpa-rg
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 signature.asc Description: PGP signature
Bug#993370: RFP: rg-el -- elpa-rg
Antoine Beaupré 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 signature.asc Description: PGP signature
Bug#993370: RFP: rg-el -- elpa-rg
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
Bug#993370: RFP: rg-el -- elpa-rg
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é 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
signature.asc
Description: PGP signature
Bug#993370: RFP: rg-el -- elpa-rg
On 2021-08-31 23:47:26, Nicholas D. Steeves wrote: [...] > 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. :) >> 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. a. -- Brief is this existence, as a fleeting visit in a strange house. The path to be pursued is poorly lit by a flickering consciousness. - Albert Einstein
Processed: Re: Bug#993370: RFP: rg-el -- elpa-rg
Processing control commands: > owner -1 ! Bug #993370 [wnpp] RFP: rg-el -- elpa-rg Owner recorded as Nicholas D Steeves . > retitle -1 ITP: rg-el -- elpa-rg: search tool for Emacs based on Ripgrep Bug #993370 [wnpp] RFP: rg-el -- elpa-rg Changed Bug title to 'ITP: rg-el -- elpa-rg: search tool for Emacs based on Ripgrep' from 'RFP: rg-el -- elpa-rg'. -- 993370: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=993370 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#993370: RFP: rg-el -- elpa-rg
Control: owner -1 ! Control: retitle -1 ITP: rg-el -- elpa-rg: search tool for Emacs based on Ripgrep > This ticket was actually requested by Nicholas, who's been working on > packaging. I'm not sure how to make that an ITP for him, so I filed an > RFP instead: > > https://salsa.debian.org/sten/rg-el > Thank you Antoine, much appreciated! > Note that there are a *lot* of wrappers around ripgrep out > there. Another commonly used one is deadgrep, which has a list of > alternatives: > > https://github.com/Wilfred/deadgrep/blob/master/docs/ALTERNATIVES.md > Deadgrep would be my second choice (and is the second most popular on MELPA), but also looks excellent :-) Micah, I've CCed you since Antoine mentioned you use Deadgrep, and because I'd be happy to answer any questions you have about the process of debianising it. I'm on holidays so am working on this RFP in 30min sprints with a fairly scientific method. If you think the process might be interesting content for Debian Planet, please let me know :-) > 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. P.S. I'm also curious if you'll end up enjoying rg.el, or if you'll find it too fancy new school thing ;-) Cheers, Nicholas signature.asc Description: PGP signature
Bug#993370: RFP: rg-el -- elpa-rg
Package: wnpp Severity: wishlist User: debian-emac...@lists.debian.org Usertags: elpafy X-Debbugs-Cc: nstee...@gmail.com, debian-emac...@lists.debian.org * Package name: rg-el Version : 2.1.0 Upstream Author : David Landell * URL : https://github.com/dajva/rg.el * License : GPL-3 Programming Lang: Elisp Description : elpa-rg search tool for Emacs based on Ripgrep Rg.el is a search package based on Ripgrep. It allows one to do interactive searches, automatic searches based on the editing context, plus adding additional query layers to refine search results. Transitioning from rgrep to rg should be painless for anyone familiar with rgrep. Unlike rgrep, ripgrep is *fast*! In some cases ripgrep is even faster than The Silver Searcher. In other words, it excells for large source code repositories. This ticket was actually requested by Nicholas, who's been working on packaging. I'm not sure how to make that an ITP for him, so I filed an RFP instead: https://salsa.debian.org/sten/rg-el Note that there are a *lot* of wrappers around ripgrep out there. Another commonly used one is deadgrep, which has a list of alternatives: https://github.com/Wilfred/deadgrep/blob/master/docs/ALTERNATIVES.md I'm not actually sure why Nicholas picked rg.el.
