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