chg has its own pager implementation that it wants to skip pager's uisetup.
It is currently done by redirecting stdout to /dev/null, which has unintended
side effects. This patch makes pager aware of chg and skip uisetup directly
from pager. We may want to merge chg and pager's pager implementation to
make this unnecessary in the future.
We want to see partial command results as soon as possible. But the buffering
mode of stdout (= pager's stdin) was set to fully-buffered because it isn't
associated with a tty. So, this patch recreates new stdout object to force its
buffering mode.
Because two file objects are associated with the same stdout fd and their
destructors will call close(), one of them must be closed carefully. Python
expects that the stdout fd never be closed even after sys.stdout.close() [1],
but newstdout has no such hack. So this patch calls newstdout.close()
immediately before duplicating the original stdout fd to sys.stdout.
operation sys.stdout newstdout fd
--------------------- ---------- --------- --------
newstdout.close() open closed closed
os.dup2(stdoutfd, ..) open closed open
del sys.stdout closed closed open [1]
[1]: https://hg.python.org/cpython/file/v2.7.10/Python/sysmodule.c#l1391
Extension authors (notably at companies using hg) have been
cargo-culting the `testedwith = 'internal'` bit from hg's own
extensions, which then defeats our "file bugs over here" logic in
dispatch. Let's be more aggressive about trying to give extension
authors a hint about what testedwith should say.
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.
