Augie Fackler <r...@durin42.com> writes:
>> On Feb 6, 2017, at 18:32, Sean Farley <s...@farley.io> wrote:
>>
>> Augie Fackler <r...@durin42.com> writes:
>>
>>>> On Feb 6, 2017, at 18:04, Sean Farley <s...@farley.io> wrote:
>>>>
>>>> Augie Fackler <r...@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.
Ok, I see. Sounds good to me.
>>> [pager]
>>> attend-foo = yes
>>
>> Is there anything preventing this form?
>
> I believe this already works...
Ha, ok, shows how much I dig into pager.attend code.
>>>>> 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...)
No worries. It's always something we can add / decide on later. I look
forward to this API and getting pager into core :-)
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
