threads / patch / 23182

patch, 2 partsTeach 'git grep' about --open-files-in-pager=[<pager>]

Subject: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

## tl;dr

20 messages between Mar 26, 2010 and Mar 29, 2010. Diffs are folded; open one to read it.

replies: 19people: 7as markdown or json

Johannes Schindelin· Mar 26, 2010, 10:48 UTC · lore

This supports opening the results of a 'git grep' directly in a pager (where the pager can be 'vi', too).

This series is purely about convenience, everything the option does can be done with a regular script or command line.

But I saw so many people doing their own scripts for that, and in many cases, they are subtly broken (e.g.

	git grep -z <expr> | xargs -0r vi +/<expr>

would work as long as you do not have to check the exit status of git grep from another script) that I finally decided to go for it and send this patch pair.

My most common use case for this is to do something like
	git grep -Ovi SomeJustRenamedFile
to edit all files I might have forgotten to change after a git mv.

(Actually, to be honest, my use case involves -Pvi, but I will have to retrain my hands.)

Johannes Schindelin (2):
  grep: Add the option '--open-files-in-pager'
  grep -P: allow optional argument specifying the pager (or editor)
 Documentation/git-grep.txt |    8 +++++
 builtin-grep.c             |   74 ++++++++++++++++++++++++++++++++++++++++++++
 git.c                      |    2 +-
 3 files changed, 83 insertions(+), 1 deletions(-)
Johannes Schindelin· Mar 26, 2010, 10:49 UTC · re: Johannes Schindelin · lore

[PATCH 1/2] grep: Add the option '--open-files-in-pager'

This adds an option to open the matching files in the pager, and if the pager happens to be "less" (or "vi") and there is only one grep pattern, it also jumps to the first match right away.

The short option was chose as '-O' to avoid clashes with GNU grep's options (as suggested by Junio).

So, 'git grep -O abc' is a short form for 'less +/abc $(grep -l abc)' except that it works also with spaces in file names, and it does not start the pager if there was no matching file.

Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-grep.txt |    8 +++++
 builtin-grep.c             |   71 ++++++++++++++++++++++++++++++++++++++++++++
 git.c                      |    2 +-
 3 files changed, 80 insertions(+), 1 deletions(-)
Show changes to 3 files +80 −1

Documentation/git-grep.txt, builtin-grep.c, git.c

diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index e019e76..ab3bb77 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -15,6 +15,7 @@ SYNOPSIS
 	   [-E | --extended-regexp] [-G | --basic-regexp]
 	   [-F | --fixed-strings] [-n]
 	   [-l | --files-with-matches] [-L | --files-without-match]
+	   [-O | --open-files-in-pager]
 	   [-z | --null]
 	   [-c | --count] [--all-match] [-q | --quiet]
 	   [--max-depth <depth>]
@@ -101,6 +102,13 @@ OPTIONS
 	For better compatibility with 'git diff', --name-only is a
 	synonym for --files-with-matches.
 
+-O::
+--open-files-in-pager::
+	Open the matching files in the pager (not the output of 'grep').
+	If the pager happens to be "less" or "vi", and the user
+	specified only one pattern, the first file is positioned at
+	the first match automatically.
+
 -z::
 --null::
 	Output \0 instead of the character that normally follows a
diff --git a/builtin-grep.c b/builtin-grep.c
index 5d83d9b..233c772 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -14,6 +14,7 @@
 #include "userdiff.h"
 #include "grep.h"
 #include "quote.h"
+#include "string-list.h"
 
 #ifndef NO_PTHREADS
 #include "thread-utils.h"
@@ -517,6 +518,31 @@ static int grep_file(struct grep_opt *opt, const char *filename)
 	}
 }
 
+static void append_path(struct grep_opt *opt, const void *data, size_t len)
+{
+	struct string_list *path_list = opt->output_priv;
+
+	if (len == 1 && *(char *)data == '\0')
+		return;
+	string_list_append(xstrndup(data, len), path_list);
+}
+
+static void run_pager(struct grep_opt *opt, const char *prefix)
+{
+	struct string_list *path_list = opt->output_priv;
+	char **argv = xmalloc(sizeof(const char *) * (path_list->nr + 1));
+	int i;
+
+	for (i = 0; i < path_list->nr; i++)
+		argv[i] = path_list->items[i].string;
+	argv[path_list->nr] = NULL;
+
+	if (prefix)
+		chdir(prefix);
+	execvp(argv[0], argv);
+	error("Could not run pager %s: %s", argv[0], strerror(errno));
+}
+
 static int grep_cache(struct grep_opt *opt, const char **paths, int cached)
 {
 	int hit = 0;
@@ -727,9 +753,11 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 	int cached = 0;
 	int seen_dashdash = 0;
 	int external_grep_allowed__ignored;
+	int show_in_pager = 0;
 	struct grep_opt opt;
 	struct object_array list = { 0, 0, NULL };
 	const char **paths = NULL;
+	struct string_list path_list = { NULL, 0, 0, 0 };
 	int i;
 	int dummy;
 	struct option options[] = {
@@ -810,6 +838,8 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 		OPT_BOOLEAN(0, "all-match", &opt.all_match,
 			"show only matches from files that match all patterns"),
 		OPT_GROUP(""),
+		OPT_BOOLEAN('O', "open-files-in-pager", &show_in_pager,
+			"show matching files in the pager"),
 		OPT_BOOLEAN(0, "ext-grep", &external_grep_allowed__ignored,
 			    "allow calling of grep(1) (ignored by this build)"),
 		{ OPTION_CALLBACK, 0, "help-all", &options, NULL, "show usage",
@@ -862,6 +892,20 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 		argc--;
 	}
 
+	if (show_in_pager) {
+		const char *pager = getenv("GIT_PAGER");
+		if (!pager)
+			pager = getenv("PAGER");
+		if (!pager)
+			pager = "less";
+		opt.name_only = 1;
+		opt.null_following_name = 1;
+		opt.output_priv = &path_list;
+		opt.output = append_path;
+		string_list_append(pager, &path_list);
+		use_threads = 0;
+	}
+
 	if (!opt.pattern_list)
 		die("no pattern given.");
 	if (!opt.fixed && opt.ignore_case)
@@ -921,6 +965,29 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 		paths[1] = NULL;
 	}
 
+	if (show_in_pager && (cached || list.nr))
+		die ("--open-files-in-pager only works on the worktree");
+
+	if (show_in_pager && opt.pattern_list && !opt.pattern_list->next) {
+		const char *pager = path_list.items[0].string;
+		int len = strlen(pager);
+
+		if (len > 4 && is_dir_sep(pager[len - 5]))
+			pager += len - 4;
+
+		if (!strcmp("less", pager) || !strcmp("vi", pager)) {
+			struct strbuf buf = STRBUF_INIT;
+			strbuf_addf(&buf, "+/%s%s",
+					strcmp("less", pager) ? "" : "*",
+					opt.pattern_list->pattern);
+			string_list_append(buf.buf, &path_list);
+			strbuf_detach(&buf, NULL);
+		}
+	}
+
+	if (!show_in_pager)
+		setup_pager();
+
 	if (!list.nr) {
 		if (!cached)
 			setup_work_tree();
@@ -943,6 +1010,10 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 
 	if (use_threads)
 		hit |= wait_all();
+
+	if (hit && show_in_pager)
+		run_pager(&opt, prefix);
+
 	free_grep_patterns(&opt);
 	return !hit;
 }
diff --git a/git.c b/git.c
index 4c3028c..4def718 100644
--- a/git.c
+++ b/git.c
@@ -317,7 +317,7 @@ static void handle_internal_command(int argc, const char **argv)
 		{ "fsck-objects", cmd_fsck, RUN_SETUP },
 		{ "gc", cmd_gc, RUN_SETUP },
 		{ "get-tar-commit-id", cmd_get_tar_commit_id },
-		{ "grep", cmd_grep, RUN_SETUP | USE_PAGER },
+		{ "grep", cmd_grep, RUN_SETUP },
 		{ "hash-object", cmd_hash_object },
 		{ "help", cmd_help },
 		{ "index-pack", cmd_index_pack },
-- 
1.6.4.313.g3d9e3
Jonathan Nieder· Mar 28, 2010, 04:09 UTC · re: Johannes Schindelin · lore

Re: [PATCH 1/2] grep: Add the option '--open-files-in-pager'

Hi,
Johannes Schindelin wrote:
> This adds an option to open the matching files in the pager, and if the
> pager happens to be "less" (or "vi") and there is only one grep pattern,
> it also jumps to the first match right away.
Sounds interesting.
> diff --git a/builtin-grep.c b/builtin-grep.c
> index 5d83d9b..233c772 100644

I couldn’t get this to apply to current master or maint, and searching for blob 5d83d9b to find a more suitable merge base revealed that I don’t actually have that object in my repo. Is this patch available already applied in a public git repo somewhere?

Hopeful, Jonathan

Johannes Schindelin· Mar 29, 2010, 17:13 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] grep: Add the option '--open-files-in-pager'

Hi,
On Sat, 27 Mar 2010, Jonathan Nieder wrote:
Show 9 quoted lines
> Johannes Schindelin wrote:
> 
> > diff --git a/builtin-grep.c b/builtin-grep.c
> > index 5d83d9b..233c772 100644
> 
> I couldn’t get this to apply to current master or maint, and searching 
> for blob 5d83d9b to find a more suitable merge base revealed that I 
> don’t actually have that object in my repo.  Is this patch available 
> already applied in a public git repo somewhere?
Yes, it is in 4msysgit.git's "grep-P" branch (still misnamed).

Ciao, Dscho

Junio C Hamano· Mar 29, 2010, 18:17 UTC · re: Jonathan Nieder · lore

Re: [PATCH 1/2] grep: Add the option '--open-files-in-pager'

Jonathan Nieder <jrnieder@gmail.com> writes:
> I couldn’t get this to apply to current master or maint, and searching for
> blob 5d83d9b to find a more suitable merge base revealed that I don’t
> actually have that object in my repo.  Is this patch available already
> applied in a public git repo somewhere?

This seems to be based on a fork with a not-very-recent forkpoint. I managed to create a topic branch and merged it to 'pu'.

It probably wants to be adjusted to --no-index mode, as that is also about finding strings in files in the filesystem, but I chose not to do that myself. For this topic to go forward I think it needs a rebase to a more recent 'master'.

Johannes Schindelin· Mar 26, 2010, 10:49 UTC · re: Johannes Schindelin · lore

[PATCH 2/2] grep -P: allow optional argument specifying the pager (or editor)

Suppose you want to edit all files that contain a specific search term. Of course, you can do something totally trivial such as

	git grep -z -e <term> | xargs -0r vi +/<term>
but maybe you are happy that the same will be achieved by
	git grep -Ovi <term>
now.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
 Documentation/git-grep.txt |    6 +++---
 builtin-grep.c             |   21 ++++++++++++---------
 2 files changed, 15 insertions(+), 12 deletions(-)
Show changes to 2 files +15 −11

Documentation/git-grep.txt, builtin-grep.c

diff --git a/Documentation/git-grep.txt b/Documentation/git-grep.txt
index ab3bb77..1b7e32d 100644
--- a/Documentation/git-grep.txt
+++ b/Documentation/git-grep.txt
@@ -15,7 +15,7 @@ SYNOPSIS
 	   [-E | --extended-regexp] [-G | --basic-regexp]
 	   [-F | --fixed-strings] [-n]
 	   [-l | --files-with-matches] [-L | --files-without-match]
-	   [-O | --open-files-in-pager]
+	   [(-O | --open-files-in-pager) [<pager>]]
 	   [-z | --null]
 	   [-c | --count] [--all-match] [-q | --quiet]
 	   [--max-depth <depth>]
@@ -102,8 +102,8 @@ OPTIONS
 	For better compatibility with 'git diff', --name-only is a
 	synonym for --files-with-matches.
 
--O::
---open-files-in-pager::
+-O [<pager>]::
+--open-files-in-pager [<pager>]::
 	Open the matching files in the pager (not the output of 'grep').
 	If the pager happens to be "less" or "vi", and the user
 	specified only one pattern, the first file is positioned at
diff --git a/builtin-grep.c b/builtin-grep.c
index 233c772..a23f0dc 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -753,7 +753,7 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 	int cached = 0;
 	int seen_dashdash = 0;
 	int external_grep_allowed__ignored;
-	int show_in_pager = 0;
+	const char *show_in_pager = NULL, *default_pager = "dummy";
 	struct grep_opt opt;
 	struct object_array list = { 0, 0, NULL };
 	const char **paths = NULL;
@@ -838,8 +838,9 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 		OPT_BOOLEAN(0, "all-match", &opt.all_match,
 			"show only matches from files that match all patterns"),
 		OPT_GROUP(""),
-		OPT_BOOLEAN('O', "open-files-in-pager", &show_in_pager,
-			"show matching files in the pager"),
+		{ OPTION_STRING, 'O', "open-files-in-pager", &show_in_pager,
+			"pager", "show matching files in the pager",
+			PARSE_OPT_OPTARG, NULL, (intptr_t)default_pager },
 		OPT_BOOLEAN(0, "ext-grep", &external_grep_allowed__ignored,
 			    "allow calling of grep(1) (ignored by this build)"),
 		{ OPTION_CALLBACK, 0, "help-all", &options, NULL, "show usage",
@@ -893,16 +894,18 @@ int cmd_grep(int argc, const char **argv, const char *prefix)
 	}
 
 	if (show_in_pager) {
-		const char *pager = getenv("GIT_PAGER");
-		if (!pager)
-			pager = getenv("PAGER");
-		if (!pager)
-			pager = "less";
+		if (show_in_pager == default_pager) {
+			show_in_pager = getenv("GIT_PAGER");
+			if (!show_in_pager)
+				show_in_pager = getenv("PAGER");
+			if (!show_in_pager)
+				show_in_pager = "less";
+		}
 		opt.name_only = 1;
 		opt.null_following_name = 1;
 		opt.output_priv = &path_list;
 		opt.output = append_path;
-		string_list_append(pager, &path_list);
+		string_list_append(show_in_pager, &path_list);
 		use_threads = 0;
 	}
 
-- 
1.6.4.313.g3d9e3
Bert Wesarg· Mar 26, 2010, 11:39 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

On Fri, Mar 26, 2010 at 11:48, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 28 quoted lines
>
> This supports opening the results of a 'git grep' directly in a pager
> (where the pager can be 'vi', too).
>
> This series is purely about convenience, everything the option does can
> be done with a regular script or command line.
>
> But I saw so many people doing their own scripts for that, and in many
> cases, they are subtly broken (e.g.
>
>        git grep -z <expr> | xargs -0r vi +/<expr>
>
> would work as long as you do not have to check the exit status of git
> grep from another script) that I finally decided to go for it and send
> this patch pair.
>
> My most common use case for this is to do something like
>
>        git grep -Ovi SomeJustRenamedFile
>
> to edit all files I might have forgotten to change after a git mv.
>
> (Actually, to be honest, my use case involves -Pvi, but I will have to
> retrain my hands.)
>
> Johannes Schindelin (2):
>  grep: Add the option '--open-files-in-pager'
>  grep -P: allow optional argument specifying the pager (or editor)
Your re-training failed miserable ;-)

I like the idea. But could it make sense to get the line number of the first match to the filename. In the same syntax as on the console (i.e. <file>:<line>:)?

I have also the feeling that -O potion does not like pager with arguments, be it from GIT_PAGER, PAGER, or from the command line.

Regards, Bert

Johannes Schindelin· Mar 26, 2010, 16:18 UTC · re: Bert Wesarg · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Hi,
On Fri, 26 Mar 2010, Bert Wesarg wrote:
Show 32 quoted lines
> On Fri, Mar 26, 2010 at 11:48, Johannes Schindelin
> <Johannes.Schindelin@gmx.de> wrote:
> >
> > This supports opening the results of a 'git grep' directly in a pager
> > (where the pager can be 'vi', too).
> >
> > This series is purely about convenience, everything the option does can
> > be done with a regular script or command line.
> >
> > But I saw so many people doing their own scripts for that, and in many
> > cases, they are subtly broken (e.g.
> >
> >        git grep -z <expr> | xargs -0r vi +/<expr>
> >
> > would work as long as you do not have to check the exit status of git
> > grep from another script) that I finally decided to go for it and send
> > this patch pair.
> >
> > My most common use case for this is to do something like
> >
> >        git grep -Ovi SomeJustRenamedFile
> >
> > to edit all files I might have forgotten to change after a git mv.
> >
> > (Actually, to be honest, my use case involves -Pvi, but I will have to
> > retrain my hands.)
> >
> > Johannes Schindelin (2):
> >  grep: Add the option '--open-files-in-pager'
> >  grep -P: allow optional argument specifying the pager (or editor)
> 
> Your re-training failed miserable ;-)
It would have if I said that it is finished.
> I like the idea. But could it make sense to get the line number of the 
> first match to the filename. In the same syntax as on the console (i.e. 
> <file>:<line>:)?

See Peff's mail, and my answer to it for an explanation why it would actively _not_ help me that way.

> I have also the feeling that -O potion does not like pager with
> arguments, be it from GIT_PAGER, PAGER, or from the command line.

You are correct. That's why I said "-O[<pager>]" and not "-O[<pager-with-arguments-that-cause-whitespace-problems-especially-with-spaces-in-directory-names-so-you-need-to-make-a-script-wrapper-anyway>]"

Of course, if you would find that useful, nobody stops you from making a patch on top of my patch pair.

Ciao, Dscho

Bert Wesarg· Mar 26, 2010, 20:07 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Hi,

On Fri, Mar 26, 2010 at 17:18, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 5 quoted lines
>> I have also the feeling that -O potion does not like pager with
>> arguments, be it from GIT_PAGER, PAGER, or from the command line.
>
> You are correct. That's why I said "-O[<pager>]" and not
> "-O[<pager-with-arguments-that-cause-whitespace-problems-especially-with-spaces-in-directory-names-so-you-need-to-make-a-script-wrapper-anyway>]"

I don't know how common it is to have arguments for the pager in GIT_PAGER or PAGER or whether git actually support this, but your first patch definitely does not work with this, regardless of your -O[<pager>] addition of the second patch.

Bert
Jeff King· Mar 26, 2010, 12:46 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

On Fri, Mar 26, 2010 at 11:48:41AM +0100, Johannes Schindelin wrote:
> This supports opening the results of a 'git grep' directly in a pager 
> (where the pager can be 'vi', too).

This is not an argument against your patch, but you may be interested in an alternate method:

  git grep -n $pattern >grep.out
  vim -q grep.out

The advantage is that the editor understands the output as a "quickfix" list and lets you cycle through the hits (just like you might with compiler errors). The disadvantage is that quickfix is a vim extension, so "less" and stock "vi" can't do this (I imagine emacs has a similar feature). It's also obviously a little more typing, but you can hide it inside an alias quite easily.

I use the same trick to look for "^<<<<<<<", and have vim cycle through merge conflicts (you can also make it quicker by restricitng the grep only to unmerged files).

-Peff
Johannes Schindelin· Mar 26, 2010, 16:14 UTC · re: Jeff King · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Hi,
On Fri, 26 Mar 2010, Jeff King wrote:
Show 16 quoted lines
> On Fri, Mar 26, 2010 at 11:48:41AM +0100, Johannes Schindelin wrote:
> 
> > This supports opening the results of a 'git grep' directly in a pager 
> > (where the pager can be 'vi', too).
> 
> This is not an argument against your patch, but you may be interested in 
> an alternate method:
> 
>   git grep -n $pattern >grep.out vim -q grep.out
> 
> The advantage is that the editor understands the output as a "quickfix" 
> list and lets you cycle through the hits (just like you might with 
> compiler errors). The disadvantage is that quickfix is a vim extension, 
> so "less" and stock "vi" can't do this (I imagine emacs has a similar 
> feature). It's also obviously a little more typing, but you can hide it 
> inside an alias quite easily.

In addition to the disadvantages you are listing, it does not jump directly to the word I am looking for. As you know, I am working with LaTeX files heavily, where convention dictates that a paragraph is represented by a single line in the source code.

So yes, I really need -O, and if a colleague would not have asked me why this useful feature is not in upstream Git, I would not even have submitted the patch pair.

Ciao, Dscho

Jeff King· Mar 26, 2010, 20:33 UTC · re: Johannes Schindelin · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

On Fri, Mar 26, 2010 at 05:14:46PM +0100, Johannes Schindelin wrote:
> In addition to the disadvantages you are listing, it does not jump 
> directly to the word I am looking for. As you know, I am working 
> with LaTeX files heavily, where convention dictates that a paragraph is 
> represented by a single line in the source code.

Sure, that is a reasonable feature to want that my solution did not have (though I have never seen LaTeX code with that requirement; I wrap my lines at a reasonable width and separate paragraphs with a blank line).

> So yes, I really need -O, and if a colleague would not have asked me why 
> this useful feature is not in upstream Git, I would not even have 
> submitted the patch pair.

Yep. That is why I started my mail with "this is not an argument against your patch". I was just trying to be helpful and offer a possible alternative.

-Peff
Junio C Hamano· Mar 26, 2010, 19:32 UTC · re: Jeff King · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Jeff King <peff@peff.net> writes:
Show 17 quoted lines
> On Fri, Mar 26, 2010 at 11:48:41AM +0100, Johannes Schindelin wrote:
>
>> This supports opening the results of a 'git grep' directly in a pager 
>> (where the pager can be 'vi', too).
>
> This is not an argument against your patch, but you may be interested in
> an alternate method:
>
>   git grep -n $pattern >grep.out
>   vim -q grep.out
>
> The advantage is that the editor understands the output as a "quickfix"
> list and lets you cycle through the hits (just like you might with
> compiler errors). The disadvantage is that quickfix is a vim extension,
> so "less" and stock "vi" can't do this (I imagine emacs has a similar
> feature). It's also obviously a little more typing, but you can hide it
> inside an alias quite easily.

"M-x grep-find" mode is designed for this, and I often run "git grep -n" in that mode.. The output is dumped into a sbuffer that is used as a "quickfix list" to bring in files with hits and jump around.

Francis Moreau· Mar 26, 2010, 20:50 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Junio C Hamano <gitster@pobox.com> writes:
Show 21 quoted lines
> Jeff King <peff@peff.net> writes:
>
>> On Fri, Mar 26, 2010 at 11:48:41AM +0100, Johannes Schindelin wrote:
>>
>>> This supports opening the results of a 'git grep' directly in a pager 
>>> (where the pager can be 'vi', too).
>>
>> This is not an argument against your patch, but you may be interested in
>> an alternate method:
>>
>>   git grep -n $pattern >grep.out
>>   vim -q grep.out
>>
>> The advantage is that the editor understands the output as a "quickfix"
>> list and lets you cycle through the hits (just like you might with
>> compiler errors). The disadvantage is that quickfix is a vim extension,
>> so "less" and stock "vi" can't do this (I imagine emacs has a similar
>> feature). It's also obviously a little more typing, but you can hide it
>> inside an alias quite easily.
>
> "M-x grep-find" mode is designed for this,
Do you mean "M-x grep" ? I don't see the point to use "M-x grep-find".
> and I often run "git grep -n" in that mode..

I always need to pass the '--no-pager' switch: "git --no-pager grep -n" since git doesn't detect that its output is sent to a 'dumb' terminal.

-- 
Francis
Junio C Hamano· Mar 27, 2010, 01:09 UTC · re: Francis Moreau · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Francis Moreau <francis.moro@gmail.com> writes:
>> and I often run "git grep -n" in that mode..
>
> I always need to pass the '--no-pager' switch: "git --no-pager grep -n"
> since git doesn't detect that its output is sent to a 'dumb' terminal.

Sorry, but as any self-respecting Emacs user would have PAGER set to cat (and EDITOR set to emacsclient), I thought nobody would need --no-pager ;-)

Francis Moreau· Mar 27, 2010, 15:19 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Junio C Hamano <gitster@pobox.com> writes:
Show 8 quoted lines
> Francis Moreau <francis.moro@gmail.com> writes:
>
>>> and I often run "git grep -n" in that mode..
>>
>> I always need to pass the '--no-pager' switch: "git --no-pager grep -n"
>> since git doesn't detect that its output is sent to a 'dumb' terminal.
>
> Sorry, but as any self-respecting Emacs user would have PAGER set to cat

Well I do, but only for "M-x shell", probably because I usually start all commands from that shell.

> (and EDITOR set to emacsclient), I thought nobody would need
> --no-pager ;-)
Indeed, I'll setup PAGER to cat when starting emacs.

That makes me think to one common operation I do which is not really convenient when PAGER is set to cat: git-log. Piping the output of git-log to a pager such as less(1) makes git-log to suspend when the pipe is full. OTOH setting PAGER to cat, git-log never blocks and for projects with a (very) long history such as git or the linux kernel, git-log can show a lot of commits making the cpu really busy and the emacs buffer really huge.

One way to workaround this is to pass -n10 for example to git-log, but it's rather ugly.

Do you have any tricks for this case ?
Thanks
-- 
Francis
Junio C Hamano· Mar 27, 2010, 17:23 UTC · re: Francis Moreau · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Francis Moreau <francis.moro@gmail.com> writes:
> Do you have any tricks for this case ?

I use PAGER=cat only inside Emacs, so I don't see how "log" can be a problem. Perhaps that is because I don't use "M-x shell" (I used to but not anymore). Of course you have to limit the extent of "log" in "M-x compile" mode, but that goes without saying.

I may have used some hooks when entering shell mode to tweak the environment further only under "M-x shell".

Francis Moreau· Mar 27, 2010, 20:29 UTC · re: Junio C Hamano · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

Junio C Hamano <gitster@pobox.com> writes:
Show 6 quoted lines
> Francis Moreau <francis.moro@gmail.com> writes:
>
>> Do you have any tricks for this case ?
>
> I use PAGER=cat only inside Emacs, so I don't see how "log" can be a
> problem.

what do you mean by this ? Do you mean that you run git-log outside emacs ?

> Of course you have to limit the extent of "log" in "M-x compile" mode,
> but that goes without saying.

Yes but in this case (log inside emacs) I was actually wondering if you were using any tricks to avoid limiting _manually_ the extent of git-log. With PAGER=less for example, the extent is _automatically_ limited by the pipe, which I found convenient.

-- 
Francis
Jon Seymour· Mar 26, 2010, 19:49 UTC · re: Jeff King · lore

Re: [PATCH 0/2] Teach 'git grep' about --open-files-in-pager=[<pager>]

On Fri, Mar 26, 2010 at 11:46 PM, Jeff King <peff@peff.net> wrote:
Show 10 quoted lines
> On Fri, Mar 26, 2010 at 11:48:41AM +0100, Johannes Schindelin wrote:
>
>> This supports opening the results of a 'git grep' directly in a pager
>> (where the pager can be 'vi', too).
>
> This is not an argument against your patch, but you may be interested in
> an alternate method:
>
>  git grep -n $pattern >grep.out
>  vim -q grep.out
Or, in bash:
    vim -q <(git grep -n $pattern)
though, of course you don't get the exit code from git.
jon.

← back to recent threads