all messages for Guix-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Efraim Flashner <efraim@flashner.co.il>
To: "LaFreniere, Joseph" <joseph@lafreniere.xyz>
Cc: 39384@debbugs.gnu.org, Marius Bakke <mbakke@fastmail.com>,
	Nicolas Goaziou <mail@nicolasgoaziou.fr>
Subject: [bug#39384] [PATCH] gnu: Add emacs-rg.
Date: Sun, 9 Feb 2020 15:28:41 +0200	[thread overview]
Message-ID: <20200209132841.GA9296@E5400> (raw)
In-Reply-To: <87h800soqr.fsf@lafreniere.xyz>

[-- Attachment #1: Type: text/plain, Size: 2461 bytes --]

On Sat, Feb 08, 2020 at 04:23:08PM -0600, LaFreniere, Joseph wrote:
> 
> Efraim Flashner <efraim@flashner.co.il> writes:
> > On Thu, Feb 06, 2020 at 06:47:23PM -0600, LaFreniere, Joseph wrote:
> > > 
> > > Marius Bakke <mbakke@fastmail.com> writes:
> > > > "LaFreniere\, Joseph" <joseph@lafreniere.xyz> 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
> > installed.
> 
> 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.

I'm not sure I can find a spot in the manual where it is detailed. It
comes down to the difference between "search for this program in PATH"
and "call this program located at this location". By calling the rg
at it's exact path rg doesn't need to be installed directly.

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

The second option is to include ripgrep as an input and patch the
package to look for it at 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

-- 
Efraim Flashner   <efraim@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

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

  reply	other threads:[~2020-02-09 13:30 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-02-01 20:28 [bug#39384] [PATCH] gnu: Add emacs-rg LaFreniere, Joseph
2020-02-01 22:09 ` Nicolas Goaziou
2020-02-02 14:21   ` LaFreniere, Joseph
2020-02-02 18:47     ` Efraim Flashner
2020-02-03  3:41       ` LaFreniere, Joseph
2020-02-04  9:58         ` Efraim Flashner
2020-02-05  3:08           ` LaFreniere, Joseph
2020-02-05  7:13             ` Efraim Flashner
2020-02-05 21:33             ` Marius Bakke
2020-02-07  0:47               ` LaFreniere, Joseph
2020-02-07 10:54                 ` Efraim Flashner
2020-02-08 22:23                   ` LaFreniere, Joseph
2020-02-09 13:28                     ` Efraim Flashner [this message]
2020-02-22 23:08                       ` LaFreniere, Joseph
2020-02-23 11:17                         ` bug#39384: " Efraim Flashner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200209132841.GA9296@E5400 \
    --to=efraim@flashner.co.il \
    --cc=39384@debbugs.gnu.org \
    --cc=joseph@lafreniere.xyz \
    --cc=mail@nicolasgoaziou.fr \
    --cc=mbakke@fastmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/guix.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.