git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Mike Coleman" <tutufan@gmail.com>
To: git@vger.kernel.org
Subject: Re: git-diff should not fire up $PAGER, period!
Date: Wed, 17 Dec 2008 20:18:38 -0600	[thread overview]
Message-ID: <3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com> (raw)

It's so cold here my car wouldn't start this morning, so I feel
fortunate to have these flames to keep me warm!  :-)


I still find git-diff's unsolicited invocation of $PAGER a bit
jarring, but I also find that I like it.  It has a sort of Windows-ish
feel to it (am I straying from the true path?).  It's convenient,
though honestly "git-diff|l" would only be two extra characters.  From
a UI perspective, the oddest thing about it is that all (not, in
fact?) of the other git programs which might also produce lengthy
output *don't* invoke $PAGER--git-status particularly comes to mind.
There are a large number of Unix programs that would be more
convenient if their output was automatically paged, but I'm not sure
it'd be better if they were all changed to do this.  (The best analog
I can think of where this seems desirable is man(1).)

To me, the most important nugget from the original complaint was that
git-diff sends its error messages to stdout.  I understand why it
might be done, but I'd worry about losing the stderr diagnostic for a
command that matters.  [I've been playing around with this for a few
minutes trying to see errors going to stdout and I can't reproduce
it--I wonder if they really do.]


Regarding the emacs complaint, as an emacs user I'd say I'm not
surprised this didn't quite work right.  In the particular case of the
compilation buffer, I wonder if the solution isn't to just unset TERM,
the existence of which (together with the fact that there's a pty)
could be taken as an invitation for the subordinate process to start
doing awful raw-terminal things.  (Similar logic applies to the
DISPLAY variable.)  Like Junio, I also eschew doing terminal emulation
inside of emacs.

Good evening from the icy midwest,
Mike

             reply	other threads:[~2008-12-18  2:20 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-12-18  2:18 Mike Coleman [this message]
2008-12-18  2:26 ` git-diff should not fire up $PAGER, period! Junio C Hamano
2008-12-18  3:22 ` Johannes Schindelin
  -- strict thread matches above, loose matches on Subject: below --
2008-12-16  0:56 git-diff should not fire up $PAGER if there is no diff Jeff King
2008-12-17 21:45 ` git-diff should not fire up $PAGER, period! jidanni
2008-12-17 22:02   ` Junio C Hamano
2008-12-17 22:04   ` Linus Torvalds
2008-12-22  3:28     ` Miles Bader
2008-12-18  3:31   ` Jeff King
2008-12-22  3:27   ` Miles Bader
2008-12-22  7:55     ` Johannes Sixt
2008-12-22  8:30       ` Junio C Hamano

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=3c6c07c20812171818k6b6e3555ja991e20d74d8291b@mail.gmail.com \
    --to=tutufan@gmail.com \
    --cc=git@vger.kernel.org \
    /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.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).