Use bzr-pager by default

I think there is a general split in the community. There are people who really wish the command would automatically bring up a pager, and then there are people like me who would really hate that. (My terminal has a scrollback, let me use it, most pagers work in bad ways with the terminal's own scrolling.) If it is really long, I probably want 'bzr XXX | gvim -R -' anyway, but I wouldn't want bzr automatically popping up gui windows.

Anyway... long story is, if we do allow this, we also need a way to disable it for people that don't want it. I'm fine going with consensus as to what the 'default' should be.

This behaviour is one of the things I really don't like in git, which is
the only other tool I can think of that does it. It would be nice if bzr
could stay consistent with the behaviour of all other 99% of the tools
on my system.
--
Jelmer Vernooij <email address hidden> - http://samba.org/~jelmer/
Jabber: <email address hidden>

On Sun, 2008-05-11 at 12:44 +0000, Jelmer Vernooij wrote:
> This behaviour is one of the things I really don't like in git, which is
> the only other tool I can think of that does it. It would be nice if bzr
> could stay consistent with the behaviour of all other 99% of the tools
> on my system.

While i wouldnt expect it to be default, it would be really nice to have
the option - its actually the only thing about git i really like.
kk

On Sun, 2008-05-11 at 13:36 +0000, KarlGoetz wrote:
> On Sun, 2008-05-11 at 12:44 +0000, Jelmer Vernooij wrote:
> > This behaviour is one of the things I really don't like in git, which is
> > the only other tool I can think of that does it. It would be nice if bzr
> > could stay consistent with the behaviour of all other 99% of the tools
> > on my system.
>
> While i wouldnt expect it to be default, it would be really nice to have
> the option - its actually the only thing about git i really like.

I think it would be fine to have a bazaar.conf option to control this.

-Rob
--
GPG key available at: <http://www.robertcollins.net/keys.txt>.

There is a bzr-pager plugin for this.

It wraps "log", "diff", "cat", "help" and "status" in calls to $PAGER.

Unfortunately, it does not work on Windows, since it uses os.fork.

The project is hosted on Launchpad (https://launchpad.net/bzr-pager) and you can install it using:
  mkdir -p ~/.bazaar/plugins
  cd ~/.bazaar/plugins
  bzr branch lp:bzr-pager pager

I wonder if the lack of activity on this bug report is indicative of lack of worry about it, so it should be gracefully retired?

Personally I dislike Git's behaviour and prefer Bazaar's behaviour -- the default of no forced pagination allows me to use terminal scroll back or pipe to paginator which works for me. If there is a plugin then perhaps this is the right thing to do.

All in all perhaps this bug should be lowered to low importance?

I reported a dup of this bug a couple of days ago after doing some diffs on the newly-released Launchpad tree that were taking (according to 'time') 26.6 seconds.

I forgot '| less -S' on one occasion, and by the time the command has finished running for the second time, that's a whole minute of my time disappeared; if I wander off and boil too many kettles per hour, I end up needing to get rid of it aswell...

It is not a problem with Git, (a) because Git tends to be about 10x faster at this sort of time-consuming operation and (b) Git already fires up the PAGER when it's going to overflow my screen.

Put simply, either Bzr badly needs the PAGER automation, or it needs to get *alot* faster; adding 5 lines to fire up the pager is going to take less implementation time. It's perfectly fine to have an option to _disable_ the auto-paging, but currently there isn't the capability to enable it either.

Firing up the pager isn't as trivial as all that, windows needs to be
accomodated, pagers tend to interfere with colourisation, and so on.

Theres also a pretty strong argument that your shell/terminal should
take care of automatic pagination - outputting variable amounts of
output is not unique to VCS tools, and having every tool implement the
same handling code is mere duplications.

Please feel free to file bug reports on performance; we take it
seriously, and 30 seconds to get a diff is abominable (presuming hot
disk cache for both bzr and the working tree inodes).

-Rob

I'd like to see it done in core, obviously with an option either way. The fact that there are some edge cases doesn't mean it shouldn't be done at all.

One thing that we strive hard for in Ubuntu is /shipping with good defaults/. The intent is not to take away the freedom to customise from hardcore users prepared to read a man page, but to give the best, default, first-time impression to new and intermediate users.

For the sake of the first-time users, intermediate users, even potential git convertees... it would be useful to ship bzr with the pager enabled by default.

This to me is a no-brainer, gives a good impresison, fixes it for the silent majority and shifts the customisation step on to the power-user, rather than the novice.

I just learned of bzr-pager.

In the mean time, I had searched for this functionality in bzr (looking for a plugin package with apt-cache search), and came up empty handed.

So I wrote a utility I called "bzrp", which is bzr-with-a-pager. Any time I run 'bzrp', I get the paged bzr type output. The command is a very simple shell script that does:

#!/bin/sh
cmd=$(shift)
opts="-F -R -X"
exec bzr $cmd $@ | sensible-pager $opts

For the time being, I have packaged 'bzrp' in a catch-all package/project called 'bikeshed', already uploaded to Natty. If you would like this very simple tool in bzr core, I'll be happy to turn it over to you.

What I like about 'bzrp' is that I can consciously use 'bzr' when I don't want paged output, or just use 'bzrp' when I do.

:-Dustin

Fantastic thought Paul,
Thanks for bzr-pager. I've branched it and i'll have a play :)

My understanding is that a patch for pager-by-default for this would now be accepted. The question is then how to do this, either:

  a. keeping it as a plugin, and shipping/enabling that by default
  b. folding paging directly in to the main program

Whoever does it can choose, but I would go for

>  b. folding paging directly in to the main program

That doesn't mean it can't be still fairly localized, but it's fine to
have it in the main tree.

--
Martin

I vote for this option, too!

Customizability via bazaar.conf (ideally overridable in branch.conf) sounds like the best idea to me.

I also want to thank Paul for his post on Good Defaults™ ☺ . This is something I think needs to be remembered on a regular basis, because it's easy to get sucked into the code when hacking and lose perspective of the common user. I don't know whether turning this on or off would be the “good” default, but I’m personally fine with either as long as I can customize it.

There's also the case of the output of "bzr log" being so long that the top of the log with the most recent entries is past the default scrollback limit for your terminal emulator of choice. Presumably you wanted to check out some of the more recent log entries rather than the initial import anyways. I am very much in favor of making this customizable, if not default

A note regarding configuration, and handling this in a way that ensures people can easily turn it off: git looks at the environment variable $GIT_PAGER in preference to $PAGER, and also checks the configuration setting core.pager, as well as command-specific pager.(command) settings. This makes it easy to disable the pager for any or all commands, by setting one of these values to "cat". (git avoids spawning a separate process in this case, rather than actually feeding all output through cat.)

Similarly, I'd suggest that bzr could check $BZR_PAGER, the user's bzr configuration, and $PAGER, in that order. Anyone could then configure the pager behavior they prefer for bzr, which may differ from the pager behavior they prefer for other tools (such as "man").

That just leaves the question of the default: whether to automatically page long output by default, or only when explicitly configured.

I would suggest that the auto-pager behavior seems more friendly as a default, since it ensures that users can easily see the output they expected. Much like the "man" command, many bzr commands normally generate a large amount of output, and spawning a pager by default seems helpful for the same reasons, notably starting the user at the beginning with the ability to scroll down or search. It seems to me like that represents the right behavior to use for people who don't provide explicit configuration; I would propose that preferring to use terminal scrollback seems like the less common preference, and that people with that preference won't have any trouble setting the pager to "cat" either in bzr's configuration or the $BZR_PAGER environment variable.

Also, people who prefer to see the output in their terminal's scrollback may find less's -X option useful, which disables the terminal initialization that normally results in using the "alternate screen" in xterm-compatible terminals. Using that option will ensure that the output goes to your terminal's normal screen, and thus that you can see it with scrollback. bzr may want to set this and other options by default if not overridden; git sets LESS=FRSX if $LESS does not already have a value.

In my opinion, this is a major drawback of bzr over git. I'm reluctant to install the bzr-pager plugin because it won't always be on all my machines, better to learn to use less, but it's a PITA. I agree with the on-by-default, disabled in bzr.conf crowd.

I agree with JoshTriplett (comment #17). Having a pager by default does seem rather more user-friendly, and an environment variable is a pretty good place to put it. This should be plainly documented in the man page, so that users who do not like that behaviour can turn it off by setting the variable to "" or "cat" or some such.

A fix has been proposed for merging into the main branch: https://code.launchpad.net/~dvedder95/bzr/pager.