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
