On Mon, Feb 03, 2014 at 11:36:15PM -0800, 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. I think the most obvious command that needs
a pager is 'help', because whenever I run 'svn help' I see the
bottom list of global options first while I'm usually looking for
information near the top of the output.
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.
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 (probably needs hooks in
svn_cmdline_printf() etc.) but might well be worth trying.
To avoid the problem where a command takes a lot of time to even fill
the screen, we could copy data to stdout as we buffer it and rely on
the pager to clear the screen when it starts up (less even has an option
to enforce this).
> 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. They do
> this by setting the LESS environment variable (if not already set and the pager
> has no arguments). In our case I'd suggest FX. I guess R doesn't do much for
> us at this point since we don't emit color codes and S seems like a bad idea
> for a default.
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.
> Branko convinced me that we should default to less (or more on Windows) if
> PAGER and SVN_PAGER is missing.
Branko also told me during a conversation we had at FOSDEM that he
believes we should never use a pager unless PAGER or SVN_PAGER is set.
Branko occasionally tends to contradict himself though :)
> So I'd like to see the following configuration:
> [helpers]
> enable-pager=yes|no (defaults to yes)
> pager-cmd=command [args] (defaults to SVN_PAGER, or PAGER or configure time choice)
>
> [blame]
> enable-pager=default|yes|no (default uses whatever yes/no state is on the
> helpers section)
> pager-cmd=command [args] (defaults to whatever the configuration of the helpers
> section was)
>
> and so on for additional sub-commands.
I had something like this in an early draft of my patch:
"### Set pager-cmd to the command used to invoke your external pager"NL
"### of choice. The command-line client will pipe output of commands"NL
"### listed in the 'paged-subcommands' option to the pager-cmd." NL
"### The default value of this option is 'more', unless the PAGER" NL
"### environment variable is set, which overrides the default." NL
"# pager-cmd = more" NL
"### Set paged-subcommands to a comman-separated list of subcommands"NL
"### The default is 'help', so 'svn help' will use a pager." NL
"# paged-subcommands = help" NL
If we do allow per-subcommand configuration, then a list like this
is sufficient, I think. I'm not sure it's worth bothering with a
per-subcommand configurable pager (though I do know that e.g. maxb
has mentioned this as a necessary feature).
If we manage to decide to run a pager based on the amount of output,
then I don't see a need for any client config options at all, except
perhaps a pager-cmd (so admins can pre-configure it in /etc/subversion).
> If there are objections to putting this
> in ~/.subversion/config we could put it in ~/.subversion/cmdline to make it
> clear these are really for our command line client and not everything else.
Sure.
> Part of the reason for each sub command being configurable is so you can do
> things like pagers that colorize output and what not (e.g. things like grc).
Can't a colorizing pager decide how to colorize based on its input?
Most editors detect this automatically as well.
Received on 2014-02-04 12:20:25 CET