On 2/6/14, 10:39 AM, Branko Čibej wrote:
> Not in general; the pager intercepts stdout, but we prompt to and read
> responses directly from the terminal. Only in extreme cases do we fall back to
> prompting to stderr and reading responses from stdin. All of the above is true
> for Windows, too.
>
On 06.02.2014 17:38, Ben Reser wrote:
> This does raise another point. This means we need to defer enabling
> the automatic pager until we are actually ready to display output
> because the pager will block prompting for passwords.
Not in general; the pager intercepts stdout, but we prompt to and
On 2/6/14, 12:26 AM, Branko Čibej wrote:
> Please, not another command-line option that's an alias for something we
> already do. --config-option:config:pager= should be enough. "env SVN_PAGER=
> PAGER=" also works.
>
> If we add --no-pager, we may as well add --no-editor, and I hope we can agree
On Thu, Feb 06, 2014 at 12:49:20PM +0100, Johan Corveleyn wrote:
> So how about making 'svn help foo' very concise and have 'svn help foo
> --verbose' give you the long version (with or without pager)? The
> concise version can end with a message "run 'svn help foo --verbose'
> for more".
+1, in a
On Thu, Feb 6, 2014 at 12:32 PM, Julian Foad wrote:
...
> 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 b
Stefan Sperling wrote:
> On Tue, Feb 04, 2014 at 12:37:45PM +, 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 sc
On 06.02.2014 01:25, Ben Reser wrote:
> On 2/5/14, 1:55 PM, Stefan Sperling wrote:
>> 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 a
On 2/5/14, 1:55 PM, Stefan Sperling wrote:
> 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
>
On Tue, Feb 04, 2014 at 12:37:45PM +, 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
> s
On 2/4/14, 8:26 AM, Stefan Sperling wrote:
> My current plan is to close the pager from a pool cleanup handler
> that is invoked when svn exits.
If that can be made to work reliably then that sounds great. Philip mentioned
that I was just tossing out another idea.
On Tue, Feb 04, 2014 at 08:13:37AM -0800, Ben Reser wrote:
> On 2/4/14, 1:14 AM, Philip Martin wrote:
> > We want some pattern that ensures __close is always called even when an
> > error is returned part way through. Either a pool cleanup or some sort
> > of __with_pager().
>
> Maybe a new SVN_E
On 2/4/14, 1:14 AM, Philip Martin wrote:
> We want some pattern that ensures __close is always called even when an
> error is returned part way through. Either a pool cleanup or some sort
> of __with_pager().
Maybe a new SVN_ERR macro?
SVN_ERR_PAGER(pager, func())
Which calls __close for you be
Stefan Sperling wrote:
> On Tue, Feb 04, 2014 at 12:37:45PM +, Julian Foad wrote:
>> A pager for all commands when producing more than a screenful of
>> output -- fine.
>
> For this requirement, we need to count newlines and compare the
> result to the terminal window's height, so we can make
Ben Reser wrote on Mon, Feb 03, 2014 at 23:36:15 -0800:
> 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
> pag
On Tue, Feb 04, 2014 at 01:07:56PM +, Philip Martin wrote:
> To get visible output with -F I need -X as well.
Thanks! -X makes it work for me, too.
On Tue, Feb 04, 2014 at 12:37:45PM +, Julian Foad wrote:
> A pager for all commands when producing more than a screenful of output --
> fine.
For this requirement, we need to count newlines and compare the
result to the terminal window's height, so we can make a decision
to launch a pager.
I
Stefan Sperling writes:
> And if I set PAGER="less -F" and run a command which produces output
> that does not fill the terminal completely I don't see any output at all.
> It seems the pager decides to exit immediately and we're writing to a
> dead fd instead of stdout. I'm not sure what to do h
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 le
On Tue, Feb 4, 2014 at 6:12 AM, Branko Čibej wrote:
> I've changed my mind since and now firmly stand by the position that I
> never, ever suggested anything other than having a no-pager default. :)
>
> I'm also somewhat opposed to the idea of having pager configuration crud for
> each client subc
On 04.02.2014 12:18, Stefan Sperling wrote:
> 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 :)
Please ... it's called "looking at both sides of the
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
On 04.02.2014 08:36, Ben Reser wrote:
> Branko convinced me that we should default to less (or more on
> Windows) if PAGER and SVN_PAGER is missing.
I've changed my mind since and now firmly stand by the position that I
never, ever suggested anything other than having a no-pager default. :)
I'm a
On Tue, Feb 04, 2014 at 09:14:52AM +, Philip Martin wrote:
> We want some pattern that ensures __close is always called even when an
> error is returned part way through. Either a pool cleanup or some sort
> of __with_pager(). Otherwise we have to ensure that none of the error
> pass bypass __
Ben Reser writes:
> On 2/3/14, 4:31 PM, Daniel Shahaf wrote:
>> Do you need to call __close if there is an error after __start? i.e.,
>> is there a state in which stdout will be printed to in the error path?
>
> Yes you do. Just try running svn diff against a non-working copy. You'll end
> up
On 2/3/14, 12:02 PM, Stefan Sperling wrote:
> Below is a very simple proof of concept patch that enables a
> pager for 'help', 'diff', and 'blame'. Currently it only looks
> for a PAGER or SVN_PAGER environment variable. My plan is to
> also add a 'pager-cmd' option for this purpose.
I suspect we
On 2/3/14, 4:31 PM, Daniel Shahaf wrote:
> Do you need to call __close if there is an error after __start? i.e.,
> is there a state in which stdout will be printed to in the error path?
Yes you do. Just try running svn diff against a non-working copy. You'll end
up with a broken terminal that y
Stefan Sperling wrote on Mon, Feb 03, 2014 at 21:02:50 +0100:
> Thoughts?
>
> @@ -316,6 +317,9 @@ svn_cl__blame(apr_getopt_t *os,
>"mode"));
> }
>
> + if (!opt_state->non_interactive && !opt_state->xml)
> +SVN_ERR(svn_cl__start_pager(&pager_proc, poo
I would like to discuss the idea of using a pager by default
for some commands.
This has been discussed before, e.g. here:
http://svn.haxx.se/dev/archive-2004-09/0132.shtml
and here: http://svn.haxx.se/users/archive-2009-08/0602.shtml
Both discussions were inconclusive. Generally people seem to
f
28 matches
Mail list logo
