[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