GNU bug report logs -
#39384
[PATCH] gnu: Add emacs-rg.
Previous Next
Full log
Message #14 received at 39384 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
On Sun, Feb 02, 2020 at 08:21:52AM -0600, LaFreniere, Joseph wrote:
> Thank you for the fast feedback!
>
> Nicolas Goaziou <mail <at> nicolasgoaziou.fr> writes:
> > Nitpick: I think the trend is to align `base32' with the string.
>
> > You may want to lint your package. In particular, the synopsis should be
> > akin to "Search tool based ..."
>
> > The description must start with a full sentence, e.g., "rg.el" is an
> > Emacs search package...
>
> > Texinfo requires two spaces after the full stop.
>
> > Ditto. Besides, the quote after "users" looks suspicious. You should use
> > a regular quote.
>
> A patch file is attached that addresses all of the above feedback. The
> output of `guix lint emacs-rg` is now clean on my system; thank you for
> making me aware of that utility.
>
> The only part of the package I'm uncertain about is declaring ripgrep as a
> propagated dependency. ripgrep is not needed for this Emacs package to be
> able to byte-compile successfully, but `rg` does not need to be on PATH for
> the package to be useful at all. So while I imagine the majority of the
> uses-cases would want to have ripgrep installed locally, it's definitely
> plausible that one could only ever want to use emacs-rg via TRAMP in which
> case pulling in ripgrep would be completely unnecessary.
>
> Please let me know what you think.
Is it possible to patch the invocations of `rg` to refer to ripgrep
directly?
--
Efraim Flashner <efraim <at> flashner.co.il> אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D 14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted
[signature.asc (application/pgp-signature, inline)]
This bug report was last modified 5 years and 142 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.