[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: Tue, 4 Feb 2014 12:37:45 +0000 (GMT)

Stefan Sperling wrote:

> Ben Reser wrote:
>> I suspect we should allow the pager to be used with all our commands,
>> though most of them should be disabled by default.  I'd say the following
>> should be enabled by default:
>>   blame
>>   cat
>>   diff
>>   list
>>   log
>>   mergeinfo (at least with --show-revs)
>>   proplist
>>   status
>
> I had a similar list. [...but...]
> I would in fact be fine with having just 'help' use a pager by default.
>
> Some commands in your list could enable the pager only when acting
> recursively, e.g. 'proplist -R', because recursive operation generally
> implies more output.
>
> We could use a static list like the above, based on what cases
> we believe will produce a lot of output.

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.

The pager should not be used when stdout is not connected to a terminal, of course.

> Or we could buffer up to one screenfull of data and decide to use the
> pager based on whether the output is going to fill the entire screen.
> This is more difficult to implement [...]

Good behaviour, but don't implement it in Subversion, implement it in the pager!  GNU 'less' already has this feature built in.  If Windows/BSD/whatever doesn't have such a pager by default, the Subversion packager should provide one.  In the extreme, I'd rather see us write one and ship it as a tool than build such functionality into 'svn' itself.

>> A lot of these will make a lot more sense if we can reasonably default to
>> something like the FRSX option set that git passes to less by default. 

For those without a copy of 'man less' in front of them:

       -F or --quit-if-one-screen
              Causes less to automatically exit if the entire file can be displayed on the first screen.

       -R or --RAW-CONTROL-CHARS
              Like -r, [Causes "raw" control characters to be displayed.  The default is to display control characters using the caret notation] but only ANSI "color" escape sequences are output in "raw" form.  Unlike -r, the screen appearance is maintained correctly in most cases.

       -S or --chop-long-lines
              Causes lines longer than the screen width to be chopped rather than folded.

       -X or --no-init
              Disables sending the termcap initialization and deinitialization  strings to the terminal.  This is sometimes desirable if the deinitialization string does something unnecessary, like clearing the screen.

> less -F is causing issues for me, where I don't see any output at all if
> the output doesn't fill screen. Not sure if this is specific to OpenBSD
> or if it can also be seen on other systems.

Do you see the same problem if you pipe the output from (non-patched) 'svn' straight into the same pager?  Could it be related to '-X'?  Could it be related to the sequence in which we close things:

  close the svn_cmdline_stream_for_stdout
  close the apr_stream_from_stdout
  close the pager
  flush stdout just before returning from main()

See the 'flush' call in 'main()' -- wouldn't it make more sense to set up and tear down the pager there, rather than within each individual subcommand?

- Julian
Received on 2014-02-04 13:41:25 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.