Mon, 06 Feb 2017 22:52:47 -0500 annotate: migrate to modern pager API
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 22:52:47 -0500] rev 31019
annotate: migrate to modern pager API
Mon, 06 Feb 2017 23:55:54 -0500 ui: add a debug print right before we start the pager
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:55:54 -0500] rev 31018
ui: add a debug print right before we start the pager This makes it easier to figure out why a command is getting paginated.
Mon, 06 Feb 2017 23:42:04 -0500 ui: respect historic pager.attend-$COMMAND=no
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:42:04 -0500] rev 31017
ui: respect historic pager.attend-$COMMAND=no I'm on the fence about this behavior, but the user's intent was pretty specific and it's not expensive to support this case.
Mon, 06 Feb 2017 23:45:30 -0500 tests: clean up a bunch of pager testing that is about to be invalidated
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:45:30 -0500] rev 31016
tests: clean up a bunch of pager testing that is about to be invalidated All this attend logic and potential bugs just no longer make sense to test.
Mon, 06 Feb 2017 23:21:45 -0500 ui: add ignore-single-command functionality
Augie Fackler <augie@google.com> [Mon, 06 Feb 2017 23:21:45 -0500] rev 31015
ui: add ignore-single-command functionality This closes the last feature gap other than the attend list from the extension. For now, I'm leaving the attend list in the extension, because I'm unsure it has merit in a world where commands have been updated to take advantage of the modern API.
Wed, 15 Feb 2017 17:48:03 -0500 ui: introduce neverpager() call
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:48:03 -0500] rev 31014
ui: introduce neverpager() call I'm about to add direct paging support to some commands, and as a result we need a way to communicate from the higher layers of dispatch that paging is explicitly disabled.
Wed, 15 Feb 2017 17:47:57 -0500 pager: move more behavior into core
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:47:57 -0500] rev 31013
pager: move more behavior into core This moves the global flag and the --pager=yes logic into core. Only functionality change is that users now always get a --pager flag and can enable the pager via the flag without the extension active. Moving the flag into core exposes a defect in the ro localization, which will have to be corrected later.
Wed, 15 Feb 2017 17:47:51 -0500 pager: move pager-initiating code into core
Augie Fackler <augie@google.com> [Wed, 15 Feb 2017 17:47:51 -0500] rev 31012
pager: move pager-initiating code into core No functionality change. A previous version of this API had a category argument on ui.pager(). As I migrated the commands in core, I couldn't come up with good enough consistency in any categorization scheme so I just scrapped the whole idea. It may be worth revisiting in the future.
Thu, 16 Feb 2017 10:33:59 -0800 test-logtoprocess: use cat to wait for outputs
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 10:33:59 -0800] rev 31011
test-logtoprocess: use cat to wait for outputs Commands started by logtoprocess are running asynchronously. To be able to test the output, we need to block and wait for the output. The patch uses "| cat" to wait for such "asynchronous" outputs, to make the test more reliable. I have also written a short notice at the top, hopefully people would be aware of the pitfall when changing the test.
Thu, 16 Feb 2017 23:10:47 -0800 chgserver: move comments in config example
Jun Wu <quark@fb.com> [Thu, 16 Feb 2017 23:10:47 -0800] rev 31010
chgserver: move comments in config example "#" must be the first character of a line to mark the text as comments. So let's change the docstring.
(0) -30000 -10000 -3000 -1000 -300 -100 -10 +10 +100 +300 +1000 +3000 +10000 tip