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