sses when a signal
> was received. After all, it is the purpose of a (deadly) signal to have the
> process go away. There may be programs that know it better, like less, but
> git should not attempt to know better in general.
>
> We do apply some special behavior for certain cases like
received. After all, it is the purpose of a (deadly) signal
to have the process go away. There may be programs that know it better,
like less, but git should not attempt to know better in general.
We do apply some special behavior for certain cases like we do for the
pager. And now the case with al
On Fri, Jan 06, 2017 at 03:39:59PM +0100, Johannes Sixt wrote:
> > diff --git a/run-command.c b/run-command.c
> > index ca905a9e80..db47c429b7 100644
> > --- a/run-command.c
> > +++ b/run-command.c
> > @@ -29,6 +29,8 @@ static int installed_child_cleanup_handler;
> >
> > static void cleanup_chil
Am 06.01.2017 um 08:32 schrieb Jeff King:
On Fri, Jan 06, 2017 at 02:26:02AM -0500, Jeff King wrote:
You'll notice that it actually calls wait() on the pager. That's due to
a3da882120 (pager: do wait_for_pager on signal death, 2009-01-22), which
IIRC was addressing a very similar p
On Fri, Jan 06, 2017 at 02:32:25 -0500, Jeff King wrote:
> And here's a patch to do that. It seems to work.
Nice, thanks! This works very well for me too.
--
Trygve Aaberge
On Fri, Jan 06, 2017 at 02:26:02AM -0500, Jeff King wrote:
> You'll notice that it actually calls wait() on the pager. That's due to
> a3da882120 (pager: do wait_for_pager on signal death, 2009-01-22), which
> IIRC was addressing a very similar problem. We want to stop feeding
On Fri, Jan 06, 2017 at 01:47:52AM -0500, Jeff King wrote:
> > > To reproduce, create e.g. the alias `l = log` and run `git l`. Then press
> > > Ctrl-c. The expected behavior is that nothing happens. The actual
> > > behavior is
> > > that the pager e
On Fri, Jan 06, 2017 at 01:40:32AM -0500, Jeff King wrote:
> On Thu, Jan 05, 2017 at 03:25:29PM +0100, Trygve Aaberge wrote:
>
> > I'm experiencing an issue when using aliases for commands that open the
> > pager.
> > When I press Ctrl-c from the pager, it exits
On Thu, Jan 05, 2017 at 03:25:29PM +0100, Trygve Aaberge wrote:
> I'm experiencing an issue when using aliases for commands that open the pager.
> When I press Ctrl-c from the pager, it exits. This does not happen when I
> don't use an alias and did not happen before. It caus
I'm experiencing an issue when using aliases for commands that open the pager.
When I press Ctrl-c from the pager, it exits. This does not happen when I
don't use an alias and did not happen before. It causes problems because
Ctrl-c is also used for other things, such as canceling a s
const char *pager = git_pager(isatty(1));
@@ -69,13 +79,8 @@ void setup_pager(void)
setenv("GIT_PAGER_IN_USE", "true", 1);
/* spawn the pager */
- argv_array_push(&pager_process.args, pager);
- pager_process.use_shell = 1;
+ prepare_pager_args(&a
something to cause the file to be presented to the end user
> even git_pager() returns NULL.
>
> And that is why I didn't make this helper call git_pager() itself.
That makes sense. I didn't dig into it carefully. I saw the "pager=cat"
thing in the context of your diff
+if (!getenv("LV"))
>> +argv_array_push(&pager_process->env_array, "LV=-c");
>> +}
>
> When reading this, I had to wonder what the "..." args were supposed to
> be. I figured it out when I read the caller, but I wonder i
quot;LV=-c");
> +}
When reading this, I had to wonder what the "..." args were supposed to
be. I figured it out when I read the caller, but I wonder if a comment
would help. Also, we are expecting the pager here as the first argument,
so maybe:
void prepare_pager_args(struct c
)
+ argv_array_push(&pager_process->env_array, "LV=-c");
+}
+
void setup_pager(void)
{
const char *pager = git_pager(isatty(1));
@@ -69,13 +86,8 @@ void setup_pager(void)
setenv("GIT_PAGER_IN_USE", "true", 1);
/* spa
On Fri, Jul 03, 2015 at 10:18:45AM -0700, Junio C Hamano wrote:
> Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that
I imagine you mean 2e6c012e here.
> becomes the upstream of the spawned pager can still tell that we
> have spawned the pager and decide to do colored ou
Since 2e6c01e2, we export GIT_PAGER_IN_USE so that a process that
becomes the upstream of the spawned pager can still tell that we
have spawned the pager and decide to do colored output even when
its output no longer goes to a terminal (i.e. isatty(1)).
But we forgot to clear it from the
t;, makes sense.
>
> Except that it was not tested with -I. If you change it that way and it
> stops working on Windows, it's useless to me.
That is all true, and I didn't test on Windows, but it seems that
the feature is very old in the upstream that we can rely on, so
let's
On Thu, May 15, 2014 at 07:46:49PM +0200, Johannes Schindelin wrote:
> > We've already found the lines of interest to the user. It would be nice
> > if we could somehow point the pager at them by number, rather than
> > repeating the (slightly incompatible) search.
>
Hi,
On Thu, 15 May 2014, Jonathan Nieder wrote:
> Johannes Schindelin wrote:
> > On Wed, 14 May 2014, Junio C Hamano wrote:
>
> >> Spot on. The change, especially with "-I", makes sense.
> >
> > Except that it was not tested with -I. If you change it that way and it
> > stops working on Windows
Johannes Schindelin wrote:
> On Wed, 14 May 2014, Jeff King wrote:
>> We've already found the lines of interest to the user. It would be nice
>> if we could somehow point the pager at them by number, rather than
>> repeating the (slightly incompatible) search.
>
>
Hi,
Johannes Schindelin wrote:
> On Wed, 14 May 2014, Junio C Hamano wrote:
>> Spot on. The change, especially with "-I", makes sense.
>
> Except that it was not tested with -I. If you change it that way and it
> stops working on Windows, it's useless to me.
Are you saying that less on Windows
is to add
> > \c to the pattern instead of passing an -I option.
>
> We've already found the lines of interest to the user. It would be nice
> if we could somehow point the pager at them by number, rather than
> repeating the (slightly incompatible) search.
FWIW it is exactl
Hi Junio,
On Wed, 14 May 2014, Junio C Hamano wrote:
> Jonathan Nieder writes:
>
> >>> + if (opt.ignore_case && !strcmp("less", pager))
> >>> + string_list_append(&path_list, "-i");
> >>
> >> I have a feeling that this goes against the recent trend of not
> >> mucking wi
terest to the user. It would be nice
if we could somehow point the pager at them by number, rather than
repeating the (slightly incompatible) search.
We can do "less +25", but that only points it to the first instance (and
doesn't highlight it), whereas the current code lets the rep
Jonathan Nieder writes:
>>> + if (opt.ignore_case && !strcmp("less", pager))
>>> + string_list_append(&path_list, "-i");
>>
>> I have a feeling that this goes against the recent trend of not
>> mucking with the expectation of the users on their pagers, if I
>> recall c
Hello,
On Wed, May 14, 2014 at 11:26:54AM -0700, Jonathan Nieder wrote:
> But as is, it's an improvement, so (except that "-i" should be
> replaced by "-I") it seems like a good change.
indeed, "-I" would match the semantics of git-grep -i .
Stepan
--
To unsubscribe from this list: send the line
Hi,
Junio C Hamano wrote:
> Stepan Kasal writes:
>> --- a/builtin/grep.c
>> +++ b/builtin/grep.c
>> @@ -897,6 +897,9 @@ int cmd_grep(int argc, const char **argv, const char
>> *prefix)
>> if (len > 4 && is_dir_sep(pager[len - 5]))
>> pager += len - 4;
>>
>> +
Junio C Hamano writes:
> Stepan Kasal writes:
>
>> From: Johannes Schindelin
>> Date: Tue, 8 Feb 2011 00:17:24 -0600
>>
>> Signed-off-by: Johannes Schindelin
>> Signed-off-by: Stepan Kasal
>> ---
>> Hi,
>> this patch has been in msysgit for 3 1/4 years.
>> Stepan
>>
>> builtin/grep.c | 3 +
Stepan Kasal writes:
> From: Johannes Schindelin
> Date: Tue, 8 Feb 2011 00:17:24 -0600
>
> Signed-off-by: Johannes Schindelin
> Signed-off-by: Stepan Kasal
> ---
> Hi,
> this patch has been in msysgit for 3 1/4 years.
> Stepan
>
> builtin/grep.c | 3 +++
> 1 file changed, 3 insertions(+)
>
From: Johannes Schindelin
Date: Tue, 8 Feb 2011 00:17:24 -0600
Signed-off-by: Johannes Schindelin
Signed-off-by: Stepan Kasal
---
Hi,
this patch has been in msysgit for 3 1/4 years.
Stepan
builtin/grep.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/builtin/grep.c b/builtin/grep.c
On Thu, Aug 29, 2013 at 11:41:56AM -0400, Dale R. Worley wrote:
> I know I'm griping here, but I thought that part of the reward for
> contributing to an open-source project was as a showcase of one's
> work. Commenting your code is what you learn first in programming.
You will find that the bes
at down, I noticed that
> > the paging behavior is controlled by at least 5 things:
> >
> > the -p/--paginate/--no-pager options
> > the GIT_PAGER environment variable
> > the PAGER environment variable
> > the core.pager Git configuration variable
> > the bu
Hi,
Dale R. Worley wrote:
> That's true, but it would change the effect of using "cat" as a value:
> "cat" as a value of DEFAULT_PAGER would cause git_pager() to return
> NULL, whereas now it causes git_pager() to return "cat". (All other
> places where "cat" can be a value are translated to NUL
gt;
> the -p/--paginate/--no-pager options
> the GIT_PAGER environment variable
> the PAGER environment variable
> the core.pager Git configuration variable
> the build-in default (which seems to usually be "less")
One complication is the meaning of -p/--no-pager:
Wi
pager = getenv("PAGER");
> > if (!pager)
> > pager = DEFAULT_PAGER;
> > else if (!*pager || !strcmp(pager, "cat"))
> > pager = NULL;
>
> I guess the "else" could an
if (!pager)
> pager = DEFAULT_PAGER;
> else if (!*pager || !strcmp(pager, "cat"))
> pager = NULL;
I guess the "else" could and should be dropped. If you do so (and
possibly insert a blank lin
So I set out to verify in the code that the order of priority of pager
specification is
GIT_PAGER > core.pager > PAGER > default
I discovered that there is also a pager. configuration
variable.
I was expecting the code to be simple, uniform (with regard to the 5
sources), and reasonably well
ior. But while tracking that down, I noticed that
>> > the paging behavior is controlled by at least 5 things:
>> >
>> > the -p/--paginate/--no-pager options
>> > the GIT_PAGER environment variable
>> > the PAGER environment variable
&
paging behavior is controlled by at least 5 things:
> >
> > the -p/--paginate/--no-pager options
> > the GIT_PAGER environment variable
> > the PAGER environment variable
> > the core.pager Git configuration variable
> > the build-in default (which seems to usua
ing behavior is controlled by at least 5 things:
>
> the -p/--paginate/--no-pager options
> the GIT_PAGER environment variable
> the PAGER environment variable
> the core.pager Git configuration variable
> the build-in default (which seems to usually be "less")
> ...
>
no-pager options
the GIT_PAGER environment variable
the PAGER environment variable
the core.pager Git configuration variable
the build-in default (which seems to usually be "less")
There is documentation in git.1 and git-config.1, and the two are not
coordinated to make it clear what
John Keeping writes:
> On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
>> Matthieu Moy wrote:
>> > I find it a bit weird that Git sets the configuration for external
>> > commands, but it may make sense. No strong opinion here.
>>
>> I don't mean a setenv() kind of thing: h
On Thu, May 30, 2013 at 10:38:59PM +0530, Ramkumar Ramachandra wrote:
> Matthieu Moy wrote:
> > I find it a bit weird that Git sets the configuration for external
> > commands, but it may make sense. No strong opinion here.
>
> I don't mean a setenv() kind of thing: how would we unset it after
> t
Matthieu Moy wrote:
> I find it a bit weird that Git sets the configuration for external
> commands, but it may make sense. No strong opinion here.
I don't mean a setenv() kind of thing: how would we unset it after
that? Perhaps something like execvpe(), passing in the environment as
an argument?
Ramkumar Ramachandra writes:
> It just needs to set $PAGER or $MANPAGER before the exec(), no?
Yes, that should do the same as "man -P".
> I would argue that it should do this. $GIT_PAGER works everywhere
> else, but obviously man has no knowledge about it.
I find it a bit weird that Git sets
Matthieu Moy wrote:
> Michael Campbell writes:
>> I have my global git config pager set to 'cat', but when I do a "git
>> help ", it still uses a pager. This is especially irksome in
>> emacs shell buffers, where I am most of the time. I know I can do a
>> M-x man -> git-, but wondered if this w
Michael Campbell writes:
> I have my global git config pager set to 'cat', but when I do a "git
> help ", it still uses a pager. This is especially irksome in
> emacs shell buffers, where I am most of the time. I know I can do a
> M-x man -> git-, but wondered if this was a bug or user
> error.
I have my global git config pager set to 'cat', but when I do a "git
help ", it still uses a pager. This is especially irksome in
emacs shell buffers, where I am most of the time. I know I can do a
M-x man -> git-, but wondered if this was a bug or user
error. ("git --no-pager help " does the sa
Jeff King writes:
> if you really want it. As of 9bad723 (allow command-specific pagers in
> pager., 2010-11-17), you can even set it to an arbitrary pager for
> each git command.
Cool!
> With all those options, it's amazing that we can still have threads
> about what should page. :)
Well to b
On Fri, Aug 31, 2012 at 08:09:34PM +0200, Andreas Schwab wrote:
> writes:
>
> > Is "status" considered a plumbing layer command? Because I have often
> > wondered why it does not use the pager by default. I pipe it through
> > less all the time and i
writes:
> Junio C Hamano writes:
>
>> In other words, Porcelain (roughly speaking, those that page by
>> default when their standard output is terminal), are not "command
>> line applications"; they have a layer on top with a built-in UI.
>
> Is "status" considered a plumbing layer command?
Hav
writes:
> Is "status" considered a plumbing layer command? Because I have often
> wondered why it does not use the pager by default. I pipe it through
> less all the time and it's kind of annoying that it works differently
> than everything else.
I would be pretty
ommand? Because I have often
wondered why it does not use the pager by default. I pipe it through
less all the time and it's kind of annoying that it works differently
than everything else.
-Dave
--
To unsubscribe from this list: send the line "unsub
Emmanuel Michon writes:
> I believe UNIX recommends some rules in the «less is more» spirit when
> designing command line applications [basically listed here:
> http://en.wikipedia.org/wiki/Unix_philosophy].
That is exactly why our plumbing layer of commands (e.g. "git
diff-tree", "git rev-list"
Emmanuel Michon writes:
> Isn't the design principle superior to the wishes of the masses?
Only when you are living an ideal fantasy land.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.k
Hello,
I'm risking myself on this mailing list after looking for some advise on
IRC. Basically I know about this previous attempt
http://marc.info/?l=git&m=122955045415845&w=2 but my request has little
to do with emacs.
I believe UNIX recommends some rules in the «less is more» spirit when
design
57 matches
Mail list logo
