[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[bug#39384] [PATCH] gnu: Add emacs-rg.

From: LaFreniere, Joseph
Subject: [bug#39384] [PATCH] gnu: Add emacs-rg.
Date: Sat, 08 Feb 2020 16:23:08 -0600

Efraim Flashner <address@hidden> writes:
On Thu, Feb 06, 2020 at 06:47:23PM -0600, LaFreniere, Joseph wrote:

Marius Bakke <address@hidden> writes:
> "LaFreniere\, Joseph" <address@hidden> writes:
> > Ah, I see what you mean now. But wouldn't hard-coding the > > path to > > ripgrep in that way prevent the package from being able to > > use
> > remote systems' ripgrep binaries when running over TRAMP?
> Perhaps we could patch [emacs-rg] to do both? Use the store > prefix if
> it
> exists, and fall back to searching in PATH?

What would be the advantage of that over just searching PATH to start with?

It will still work even if you don't have ripgrep specifically

Can you point me to the Guix documentation where the functionality you're describing is explained? I have read through the description of package inputs in section 6.2.1 of Guix's manual, but I still do not explain what advantage patching the search path offers.

My understanding is that if we want to preserve both local and remote-via-TRAMP functionality, we can either
- just include ripgrep as a propagated input, or
- include ripgrep as a propagated input _and_ patch the package to look for ripgrep in a hardcoded location (for local) as well as PATH (for TRAMP).

Both options would have ripgrep included as propagated input. As soon as ripgrep is installed in a user's profile, its binary will be available on PATH. If that is correct, then I don't see any advantage to patching in a hardcoded path to ripgrep.

Joseph LaFreniere

reply via email to

[Prev in Thread] Current Thread [Next in Thread]