An upcoming patch will teach color to potentially act differently if the
pager is active. Since both extensions wrap the same function
(dispatch._runcommand) to change behavior, we must guarantee that
pager's wrapped function runs before color's so color may read the
breadcrumb left by pager.
A subsequent patch will teach the color extension to do different things
depending on whether a pager is active. This patch leaves a breadcrumb
on the ui instance to allow it do that that.
Some extensions set configuration settings that showed up in 'hg showconfig
--debug' with 'none' as source. That was confusing.
Instead, they will now tell which extension they come from.
This change tries to be consistent and specify a source everywhere - also where
it perhaps is less relevant.
If paging is configured for a command all it's internal defined aliases
will be paged as well. This will make attend=log cause 'hg history'
to run the pager. However custom aliases will not be paged by default.
Using less -S will hide possibly important information when reviewing a
changeset, e.g. something wrong/dangerous after the 80th column, because
"less" will not give an indication that following characters are hidden.
With the pager running as a child process, exiting the pager doesn't
result in a broken pipe message. To distinguish the exit broken pipe code
from a mercurial abort we register the default action for SIGPIPE. This
results in a 141 exit code instead of a 255. On windows SIGPIPE doesn't
exists and a ValueError will be thrown.
This changes how the pager extension invokes the pager. Prior to this change,
the extension would fork Hg and exec the pager in the parent process. This
loses Hg exit code, and it doesn't work on Windows.
Now the pager is invoked using the subprocess library, and an atexit handler is
registered that makes Hg wait for the pager to exit before it exits itself.
Note that if you exit the pager before Hg is done running, you'll get an exit
code of 255, which is caused by Python blowing up due to a broken pipe. If you
set pager.quiet=True, you'll get the OS-level return code of 141.
This decides when to run the pager based on the first call to
ui.write() and ui.write_err(). This has the side effect of not the
output of subprocesses that write output before hg does.
Currently, a number of commands and help topics mention the user hgrc
file in different ways. Among these are following:
1. .hgrc - "please specify your commit editor/username in your .hgrc
file", bookmarks, color, hgk, pager, hg help environment
2. $HOME/.hgrc - hg help paths, hgrc(5), hg(1)
3. ~/.hgrc - hgrc(5)
In addition to being inconsistent, none of these make sense on
Windows. This patch replaces the above with a more general term of
"[your] configuration file".
With the pager as the child process instead of the parent process, the
termination of the parent Mercurial process can cause the terminal to return
before the pager exits. Inverting the relationship prevents that issue.
Platforms without fork() will continue to use util.popen().
The default list includes commands which normally print large amounts of
text. This should be more user-friendly than paging all commands by default,
which can be confusing when the pager swallows input prompts (with, e.g.,
record, merge, HTTP/SSH authentication, etc.)
Trying as much as possible to consistently:
- use a present tense predicate followed by a direct object
- verb referring directly to the functionality provided
(ie. not "add command that does this" but simple "do that")
- keep simple and to the point, leaving details for the long help
(width is tight, possibly even more so for translations)
Thanks to timeless, Martin Geisler, Rafael Villar Burke, Dan Villiom
Podlaski Christiansen and others for the helpful suggestions.
The pager is preventing the debugger prompt and much of the
debugger output to be refreshed. Moreover the pager does not
make sense when debugging line by line.
(This supersedes the similar ui.debugflag patch. Disabling
the pager for debug output doesn't make that much sense,
as this is actually when the pager might be useful.)
The pager is preventing the debugger prompt and much of the
debugger output to be refreshed. Moreover the pager does not
make sense when debugging line by line (Thanks to Gilles Moris).
Add the configuration options pager.ignore and pager.attend.
You can disable the pager on certain commands by adding them to the
pager.ignore setting. To whitelist commands, you can add them to pager.attend.
To disable or enable global commands like 'hg version' or 'hg help'
you have to use your global .hgrc. (thanks, Matt Mackall)
