[PATCH v2] pager: migrate heavily-used extension into core

[Augie Fackler]

> On Feb 6, 2017, at 18:32, Sean Farley <sean at farley.io> wrote:
> 
> Augie Fackler <raf at durin42.com> writes:
> 
>>> On Feb 6, 2017, at 18:04, Sean Farley <sean at farley.io> wrote:
>>> 
>>> Augie Fackler <raf at durin42.com> writes:
>>> 
>>>> (sending again because this seems to have gotten stuck somewhere...)
>>>> (+yuya explicitly for chg thoughts, +smf so someone else can forward to the list if it's stuck again)
>>>> 
>>>> On Fri, Feb 03, 2017 at 04:16:09PM -0800, Bryan O'Sullivan wrote:
>> [...]
>> 
>>>> (This design, btw, was inspired by the way git handles paging, where
>>>> it's largely up to the command to decide if it wants to invoke the
>>>> pager.)
>>> 
>>> If I'm understanding you correctly, this will get rid of the
>>> pager.attend variable? If that's true, then I fully support that.
>> 
>> Mostly. pager.attend will probably live on as a config knob for users to force paging of commands that don't request it. I can't see it working without that? Though it'd be the alternative form, that looks like
> 
> You mean for third-party commands?

Yep.

> My conclusion from your previous
> email was that all the internal commands would eventually be patched to
> use ui.pager, right?

Most, not all. commit doesn't really want a pager, and summary probably doesn't want it as a default? We'll have to do some fiddling around the margins, but yes, I'm thinking I'll include in my series moving log/export/diff and friends to the new API.

> 
>> [pager]
>> attend-foo = yes
> 
> Is there anything preventing this form?

I believe this already works...

> 
>>>> As a sketch of where this is headed, API-wise:
>>>> 
>>>> class ui:
>>>> def pager(self, command, category):
>>>>  ""Starts the pager, if desired by the user.
>>>> 
>>>>  `command` specifies the current command the user is running,
>>>>  something like `log` or `shelve`. It should be the whole original
>>>>  command name, not the partial name or alias name.
>>>> 
>>>>  `category` specifies a broad category this pager invocation fits
>>>>  into. Examples include `diff`, `log`, `status`, `help`. This
>>>>  allows users to disable paging of entire types of commands easily.
>>>>  """
>>>>  # pager starts, self.pageractive=true, etc
>>>> 
>>>> @command
>>>> def shelve(ui, ...):
>>>> if action == 'list':
>>>>  ui.pager('shelve', 'diff' if --patch else 'log')
>>>> ...
>>>> 
>>>> @command
>>>> def summary(ui, ...):
>>>> ui.pager('summary', 'status')
>>>> ...
>>> 
>>> Would this get rid of the need to set pager.pager=less? I think last
>>> time the pager was brought up (I believe the Munich sprint), there was a
>>> consensus on not relying on the existence of less / more / windows
>>> weirdness.
>> 
>> I don't know about Windows, but I think we should follow git's lead and default to using *a* pager. On debian, that means sensible-pager, on most other unices that means less, on some unfortunate platforms it means more. In-tree, we should probably default to more, with a recommendation that packagers specify a more reasonable default in the system-wide hgrc.
>> 
>> (I've had a PAGER environment variable for longer than I've had my dotfiles source control, but I have no idea how common this is. For some highly unscientific data, I've posted a poll on twitter: https://twitter.com/durin42/status/828742645145075712 - maybe we'll learn something.)
> 
> Hmmm, I seem to recall talk about vendoring a python pager? Didn't
> Anatoly write one?

I honestly have no idea - someone with a windows clue will probably need to fill in the sensible windows defaults.

(I'm -0 on bundling a pager, but maybe we'll have to do that on windows...)