[PATCH 3 of 3] [RFC] dispatch: setup color before pager
Yuya Nishihara
yuya at tcha.org
Sat Mar 25 00:30:05 EDT 2017
On Thu, 23 Mar 2017 23:11:02 -0400, Matt Harbison wrote:
> That seems reasonable. But color.pagermode seems broken for auto pager,
> now that everything has transitioned to the core. It works on stable (if
> the color/pager load order is right).
>
> 4.1:
>
> 1) Color wrapped dispatch._runcommand() and pager wrapped color's wrapper.
> 2) Running a command will:
> a) Call the pager wrapper, set ui.pageractive, and spawn the pager if
> True
> b) Call the color wrapper, and examine ui.pageractive to see if it cares
> about color.pagermode
> c) Call the actual command
>
> Default branch:
>
> 1) Pager settings are forced on or off in dispatch. '--pager=on' fires up
> a pager; 'auto' pager mode defers spawning a pager.
> 2) Color is setup (examining ui.pageractive), and color.mode=auto is
> resolved
> 3) Run the command
> a) spawn a pager the pager, setting ui.pageractive=True
>
> I think this means that the process of spawning the pager needs to be able
> to call color.setup() again, so that it can reexamine ui.pageractive.
> Otherwise, the only way 'ui.pageractive' is ever true when color is
> getting setup is if --pager != 'auto|off'. IDK the implications of a
> second setup, and I'm perplexed by all of the various ui objects that
> exist. I didn't check yet to see if there's any possibility to output
> before the calls to ui.pager() now. (I wonder if there are instances in
> largefiles with all of its overrides.)
>
> Thoughts?
I came to the same idea. If color.pagermode is different from color.mode,
we'll have to call color.setup() again.
More information about the Mercurial-devel
mailing list