[darcs-users] darcs-2 help behavior

[Matthias Kilian]

On Fri, Oct 03, 2008 at 02:58:07PM +0300, Dan Pascu wrote:
> When I use darcs --help with darcs 2.x, I noticed that it automatically 
> pipes output to the pager. I guess this was introduced to allow for an 
> easier navigation of the help text, however from a usability point of 
> view this is a setback as it introduces more annoyances than it helps. 
[...]
> Can someone please enlighten me if there is a way to disable the pager, 
> or if not could this behavior be revisited and if not reverted, at least 
> provide a way to disable it?

Workaround 1: put LESS=-FX into your environment (similar to what
Lele posted, but with a `-' prepented to the options, which is what
the less(1) manpage suggests).

Workaround 2: put PAGER=cat or DARCS_PAGER=cat into your environment.

BTW: contrary to the documentation, darcs does *not* use more(1)
by default if neiter DARCS_PAGER nor PAGER are defined, it really
uses less(1). From src/Darcs/Utils.lhs:

	get_viewer :: IO String
	get_viewer = getEnv "DARCS_PAGER" `catchall`
		     getEnv "PAGER" `catchall` return "less"


It maybe that darcs always piped help output to a pager, but just
recently switched to using less(1) by default (I'm running darcs
annotate on Utils.lhs, but it seems takes ages to complete).

Anyway, I fully agree that darcs shouldn't pipe into a pager for any
non-interactive stuff (like --help).

While we're at it, I'm also not a big fan of all the curses stuff;
it's disturbing during get and pull (you've to look at the terminal
the right time to get an idea what's going on), it's *really*
annoying when you're trying to record the output of, say ./ghc/darcs-all
using script(1), and it doesn't cope well with SIGWINCH (I often
see truncated progress info when reattaching to a screen(1) session
from an xterm with a different size than the terminal had on detach).

I didn't yet try a darcs without curses support, but IMHO, the only
"features" missing with curses disabled would be:

- one-key interactive actions (i.e. `y' to accept a patch during pull,
  without having to press the return key). Loosing this feature wouldn't
  hurt much.

- single line progress report during get and pull. This could be
  replaced by just printing one line per patch. People who don't
  want to see this could use `-q', and people who want to be able
  to see some status report could use SIGINFO (usually bound to ^T
  after an stty status ^T). The latter had to be implemented, though.

Ciao,
	Kili

-- 
It takes a vax to find such bugs.
		-- Miod Vallat