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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
