My debian system (sid) was recently upgraded to use darcs2 ("2.0.0
(unknown)"), and it appears that the new code automatically uses a pager when
displaying help output (in particular "darcs get --help" now launches
/usr/bin/less, whereas back in darcs1 it just dumped the whole thing to
stdout).

I know that sometimes this is a good thing, but this time it annoyed
me.. I wanted to see the help text on the screen at the same time as
the command I was about to type in, and sending it through less prevents
me from doing that. In general, if I want to use a pager, I'll append
"|less" to the command, so I frown upon programs that force this choice
upon me.

Just my two cents,
 -Brian

Brian,

I understand your feelings on this (because I had the same reservations myself).
 But people asked for it.  Maybe if there was a general clamor us to put things
back the way they were we could talk about changing it back.  I invite you to
open up the darcs-users discussion if you feel sufficiently annoyed about it.

Otherwise, just use darcs get --help | cat

Marking as wont-fix for now.

I thought it would be useful to put together a short history of this feature in
case the discussion comes up again (it's a pretty recurrent one).

Things to note
--------------
 * Some of us prefer one behaviour, and that others prefer the other. It appears
to be largely a matter of taste perhaps on an Emacs vs Vi level ;-)  [Bias
alert: I belong in the no camp, as in no automatic pager usage].
 * People in the 'no' camp can opt out by setting DARCS_PAGER to the empty
string, although this means you lose the ability to explicitly tell Darcs to use
the pager
 * Some arguments are subtle.  It's not just a case of yes/no, but *when* to use
the pager.  I'd suggest reading and thinking carefully the "epic" thread from
2008-10

Proposals
---------
- Do not hardcode cutoff (right now, 20 lines); ask terminfo for terminal height
instead
- Implement some sort of --pager flag
- Only use the pager within interactive mode

History
-------
2008-01-24
 http://bugs.darcs.net/issue610
 The key motivation for this behaviour was a UI concern, ie. that when you type
darcs help, the most important bits of the help text just scroll offscreen.  The
fact that Git also sends help output to pager was just supporting evidence.

2008-02-05 to 2008-02-23
 Patches to pipe darcs help, darcs  show authors, darcs command --help output
through the pager

2008-06-04 issue896
 http://bugs.darcs.net/issue896
 This bug points out that the feature is annoying.  We mark it wont-fix.

2008-05-10
 http://lists.osuosl.org/pipermail/darcs-users/2008-May/012072.html
 Request for ability to only use pager as needed.
 Patch written (arbitrary cut-off at 20 lines)

2008-05-14
 http://lists.osuosl.org/pipermail/darcs-users/2008-May/012139.html
 Another request to turn off this feature; seems satisfied with DARCS_PAGER=''
solution

2008-10-03
 http://lists.osuosl.org/pipermail/darcs-users/2008-October/014248.html
 Epic discussion on darcs-users, DARCS_PAGER='cat' and DARCS_PAGER='' tricks
pointed out

Phew! hopefully that captures everything :-)

Thanks for the summary! I should point out that I've gotten used to this
feature, so I don't mind it very much anymore (possibly because I've been using
git a lot, although I've noticed that git always uses a pager for the verbose
--help output and never for the terse -h usage summary, and the -h summary
usually fits in 10 or 15 lines, which seems to be a good compromise).

It may be more appropriate for a different bug, but I'll mention that the aspect
of this pager thing which really does bother me about darcs is the inconsistency
of using a pager for other output, specifically when viewing patches with "darcs
changes -i". Sometimes when I hit "y" to view a patch, I then need to hit "q" to
return to the summary, but sometimes when I hit "q" it quits darcs altogether.
Frustrating.

Just some admin-noise.  I've linked Brian's observation in msg9033 to a new
ticket, issue1660.

PS. Darcs bugtracker helpers should note that you can add any message to any
issues' messages field, which could be handy for splitting or copying bugs.  You
probably need to use the roundup-admin interface for that, though.

Hmm, I think I forgot to unset the wont-fix status in my msg9030 summary.
This needs to implemented and then discussed.