|
Size: 1219
Comment:
|
Size: 1796
Comment: rewrite to conform to style, add some thoughts
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| <<Include(A:style)>> | #pragma section-numbers 2 = Moving Pager to Core = |
| Line 4: | Line 5: |
| We think we'd like some sort of automatic pager support in core and on by default. This page exists to (roughly) document problems with the existing pager support, so we can outline a path to a real solution: | Pager is currently a hacky extension, and breaks some things in [[https://bz.mercurial-scm.org/show_bug.cgi?id=5377|odd ways]]. Given a concerted refactor, it could be much less fragile by moving it into core hg. <<TableOfContents>> == Current Problems == |
| Line 7: | Line 12: |
| 1. What should the default pager configuration '''be'''? | 1. Pager breaks interactivity of commands 1. Sometimes surprising things get paged. 1. We don't know what the default pager configuration '''be'''? |
| Line 10: | Line 17: |
| === Handling aliases === | == Proposal == |
| Line 23: | Line 30: |
| That'd solve the problem of [alias] entries not getting paged. | That'd solve the problem of `[alias]` entries not getting paged, and would avoid multi-mode commands (eg `shelve`) from always being paged. We could also have ui.interactive() produce a developer warning ('tried to use ui.interactive() after enabling the pager') to prevent interactive-with-pager-running problems. |
| Line 25: | Line 32: |
| === Handling errors === If you use --traceback, currently the error is paged. This doesn't seem ideal. |
== Handling errors == If you use --traceback, currently the error is paged. This doesn't seem ideal, but there doesn't appear to be a good solution other than always emitting the error on stderr and terminating output to the pager as soon as an error occurs. |
Moving Pager to Core
Note:
This page is primarily intended for developers of Mercurial.
Pager is currently a hacky extension, and breaks some things in odd ways. Given a concerted refactor, it could be much less fragile by moving it into core hg.
Contents
1. Current Problems
- Pager only applies to a handful of whitelisted commands, and aliases using those commands don't get paged
- Pager breaks interactivity of commands
- Sometimes surprising things get paged.
We don't know what the default pager configuration be?
Probably less, and probably set LESS=FSRX if LESS isn't already set?
2. Proposal
It looks like git just hard-codes which commands use the pager. We could probably do something similar by having a paged context manager on ui, eg:
with ui.paged:
# all ui prints here go to the pageror we could have a function to page the output, since I [augie] think that starting the pager isn't reversible:
ui.pager() # all subsequent output goes to the pager
That'd solve the problem of [alias] entries not getting paged, and would avoid multi-mode commands (eg shelve) from always being paged. We could also have ui.interactive() produce a developer warning ('tried to use ui.interactive() after enabling the pager') to prevent interactive-with-pager-running problems.
3. Handling errors
If you use --traceback, currently the error is paged. This doesn't seem ideal, but there doesn't appear to be a good solution other than always emitting the error on stderr and terminating output to the pager as soon as an error occurs.