bug-gnu-emacs
[Top][All Lists]
Advanced

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

bug#62426: [PATCH] eshell: Add 'rgrep' builtin.


From: Jim Porter
Subject: bug#62426: [PATCH] eshell: Add 'rgrep' builtin.
Date: Sat, 25 Mar 2023 12:07:37 -0700

On 3/25/2023 10:22 AM, Sean Whitton wrote:
Normally with M-x rgrep one benefits from how Emacs prompts you
separately for the parameters to the function, right?  In particular,
you get completion for the second and third parameters.  Given that,
you're unlikely to want to type 'rgrep foo bar baz' into Eshell, and not
benefit from that completion, when you could just type M-x rgrep in the
same buffer, and benefit from it.

It wouldn't be too difficult to add Pcomplete support for an "rgrep" Eshell command that calls 'M-x rgrep' under the hood. There's no reason you'd *have* to explicitly type all three arguments to 'M-x rgrep' on the command line. (Though doing this the Right Way would take a bit of effort, since we'd probably want 'eshell-eval-using-options' to automatically generate the appropriate Pcomplete function.)

Even without Pcomplete support, there's still a benefit to a command like this though: you could use Eshell to pipe the results of 'M-x rgrep' to some other command. Looking at the code for 'eshell-grep', I don't think it'd be terribly difficult to support this case.

Given this, I suggest rgrep in Eshell should be /usr/bin/rgrep.

Maybe there should be a defcustom for this ("use M-x rgrep" vs "use /usr/bin/rgrep")? Or maybe it should be easier to configure various Eshell commands so they open in a compilation buffer when appropriate? You can do this now with an alias, but the syntax is a bit tricky:

  alias rgrep 'eshell-grep grep ${append (list "-rH") $*}'

Something like this would be nicer:

  alias rgrep 'to-compilation-buffer rgrep -rH $*'

That would make it easier for users to define their own commands that work like this, which would (probably) be generally useful and provide a partial solution for this bug while we consider the available options. (My main goal with doing this now is so that we don't merge something and then change our minds later, disrupting users' habits.)





reply via email to

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