This patch makes us respect pager.attend again if the extension is
enabled. It also brings back the default attend list, so e.g. summary
is not paged by default, just like it used to be before pager was
moved into core.
This results in the default pager-attend list being empty. Sadly, we
can't let the code be that way, because some legacy extensions depend
on hooking the pager's attend list at import time (and we'd like to
not break them), and if the list is actually *empty* that triggers
magic behavior in the extension that attends everything. Instead, we
put a long, improbable command name as the only entry in the attend
list.
This closes the last feature gap other than the attend list from the
extension. For now, I'm leaving the attend list in the extension,
because I'm unsure it has merit in a world where commands have been
updated to take advantage of the modern API.
This moves the global flag and the --pager=yes logic into core. Only
functionality change is that users now always get a --pager flag and
can enable the pager via the flag without the extension active.
Moving the flag into core exposes a defect in the ro localization,
which will have to be corrected later.
No functionality change.
A previous version of this API had a category argument on
ui.pager(). As I migrated the commands in core, I couldn't come up
with good enough consistency in any categorization scheme so I just
scrapped the whole idea. It may be worth revisiting in the future.
Changeset 8b50aee1f75c removes SIGPIPE handling completely. This is wrong,
as it means that Mercurial does not exit when the pager does. Instead, raise
SignalInterrupt when SIGPIPE happens with a pager attached, to trigger the
normal exit path.
This will cause "killed!" to be printed to stderr (hence the BC warning),
but in the normal pager use case (where the pager gets both stderr and
stdout), this message is lost as we only get SIGPIPE when the pager quits.
pager replaced stdout with a line buffered version to work around glibc
deciding on a buffering strategy on the first write to stdout. This is going
to make my next patch hard, as replacing stdout will make tracking time
spent blocked on it more challenging.
Move the line buffering requirement to util.py, and remove it from pager.
This means that the abuse of ui.formatted=True and pager set to cat or equivalent
no longer results in a line-buffered output to a pipe, hence (BC), although
I don't expect anyone to be affected
The default SIGPIPE handler causes Mercurial to exit immediately, without
running any Python cleanup code (except and finally blocks, atexit handlers
etc). This creates problems if you want to do something at exit.
If we need a different exit code for broken pipe from pager, then we should
code that ourselves in Python; this appears to have been cargo-culted from
the fork implementation of pager that's no longer used, where it was needed
to stop Broken Pipe errors appearing on the user's terminal.
We've made chg utilize the common code path implemented in pager.py (by
e8fb65f5e551 and e97133c7a9dc), but the chg server does not always start
with a tty. Because of this, uisetup() of the pager extension could be
skipped on the chg server.
Kudos given to Sean Farley for dogfooding new chg and spotting this problem.
Since chg has its own _runpager implementation, it's no longer necessary to
special-case chg in the pager extension. This will effectively enable the
new chg pager code path that runs inside runcommand.
As discussed at [1], ui._runpager will be the new low-level API accepting a
pager command to actually run the pager. And ui.pager is the high-level API
which reads config directly from self.
This change is necessary for chgserver to override _runpager cleanly.
[1]: www.mercurial-scm.org/pipermail/mercurial-devel/2016-December/091656.html
Almost all sys.stdin/out/err in hgext/ and mercurial/ are replaced by util's.
There are a few exceptions:
- lsprof.py and statprof.py are untouched since they are a kind of vendor
code and they never import mercurial modules right now.
- ui._readline() needs to replace sys.stdin and stdout to pass them to
raw_input(). We'll need another workaround here.
I've caught multiple extensions in the wild lying about being
'internal', so it's time to move the goalposts on people. Goalpost
moving will continue until third party extensions stop trying to
defeat the system.
Since (b) is banned, we should do the same for (a) for consistency.
a) from mercurial import hg
from mercurial.i18n import _
b) from . import hg
from .i18n import _
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.
