[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: [PATCH] pager support for command line client

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 6 Feb 2014 11:32:47 +0000 (GMT)

Stefan Sperling wrote:

> On Tue, Feb 04, 2014 at 12:37:45PM +0000, Julian Foad wrote:
>> I do like the idea of making the output more user-friendly by using a
>> pager.  But keep it simple.  A pager by default just for help -- fine.  A pager
>> for all commands when producing more than a screenful of output -- fine.  A
>> static list of what commands we 'believe' will produce a lot of output
>> -- no.
> I've been using an automatic pager for every svn command for a day now.
> I'm starting to believe that we'll have to go with a static list.
> Turning on the pager for everything is painful, even if we tell it
> to quit itself automatically if the output doesn't fill the screen.

Hmm, that's a pity.

> Some problems I've been observing are:
> - Error messages are hidden by the pager even if the svn command
>   produces no other output. This can be fixed for many cases by
>   starting the pager as late as possible (e.g. before the subcommand
>   really starts doing work). But not for all cases. I'm not sure what
>   to do here. Perhaps we should pipe stderr to the pager as well?
> - Scripted svn commands (e.g. svn update) that produce more than a
>   screenfull of output wait for the user to close the pager (arguably, the
>   --non-interactive option should be passed by scripts, but the automatic
>   pager can break existing scripts that don't pass this options).
>   Of course, I made sure the pager isn't started if stdout is not a
>   terminal, but many automated scripts are run in a terminal (e.g. builds).
> - If no output is produced the entire screen is cleared anyway (I
>   believe this happens with git, too). This behaviour is probably
>   pager-specific.
> Ultimately, I'd be much happier with a default behaviour where commands
> that *I* usually pipe into a pager would use an automatic pager during
> interactive use. I would guess that this applies to almost everyone.

There are no commands that *I* *usually* pipe into a pager.  In nearly all situations I let the terminal be my pager: I can always
scroll back through the last few thousand lines, even in
Windows, as one of the first things I do is set the terminal window
scroll-back capacity to a large number.

Occasionally I pipe something to 'less' or 'vim -' as appropriate.

> The question then becomes which commands people usually pipe to a
> pager as a matter of habit. Should we try to make such a list or not?

If we did, it would of course be wrong for everybody.

> Perhaps the best compromise is to make just 'svn help' use a pager by
> default (so users realise that the auto-paging feature exists), and
> allow users to enable the automatic pager on a per-subcommand basis
> in the configuration file?

That sounds like the next best idea.  Provide a commented-out list as an example.

But this all does make me wonder, what problem are you really trying to solve, and is making 'svn' pipe stdout to a pager the best way of solving it?

You mentioned you'd be happy with just 'help' being paged.  Well, maybe that's because 'svn help merge' is really a manual but we haven't written it as a man page; and 'svn help foo' usually ends with a screenful of options which probably isn't what the user primarily needs to see in most cases, and so on.

- Julian
Received on 2014-02-06 12:36:20 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.