color: support a different color mode when the pager is active
MSYS on Windows has a terminal that supports the "win32" color mode
(which "auto" properly detects for us). However, a popularily configured
pager in that environment (GNU less) only supports the "ansi" color
mode.
This patch teaches color about a new config option: pagermode. It
behaves like "mode" but is only consulted when the pager is active for
the current command. MSYS users can now set "pagermode = ansi" and get a
colorful experience that just works. Previously, MSYS users would have
to live without color when using GNU less as the pager, would have to
manually configure the pager to attend every command, or would have
gibberish if "ansi" was used without the pager.
pager: ensure wrapped dispatch._runcommand runs before color's
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.
pager: set an attribute on ui indicating that a pager is active
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.
extensions: support callbacks after another extension loads
An upcoming patch will introduce a dependency between the color and
pager extensions. To prepare for this, we teach extensions how to
register callbacks that can execute when another extension loads.
This patch is based on code provided by Matt Mackall. But significant
parts have changed (such as the ability to register multiple callbacks
and the change in behavior to always call a callback).
I believe that always firing the callback is a good practice. I think
the common use for this feature will be for extensions to say "run this
one-time setup code, after this other extension if possible." Always
running the callback will facilitate this.
log: fix --follow null parent not to include revision 0
If p1 is null, ':.' is translated as '0:null'. But rangeset can't handle null,
only revision 0 was visible. Because 'null' should not be listed implicitly,
"log --follow" (without -r) should be empty if p1 is null.
Test of "hg grep -f" is added for cmdutil.walkchangerevs().
graphlog: remove useless check for empty repo when --follow is specified
This prepares for extracting common part from getgraphlogrevs() and
getlogrevs(). getlogrevs() does not handle empty repo specially.
When it was added at
d74099ac2ac1, revs were build by old-style query, '.:0'.
So I think the purpose of "len(repo) > 0" was to handle the case of . = null.
Currently it isn't necessary for 'reverse(:.)', and it does not work if repo
is not empty but p1 is null.
$ hg up null
$ hg glog --follow -T '{rev}:{node|short}\n'
o 0:
0a04b987be5a
The subsequent patch will fix this problem, so drops the wrong version for now.
graphlog: move comment and flag denoting revs might be unsorted
This prepares for extracting common part from getgraphlogrevs() and
getlogrevs(). "possiblyunsorted" exists only in getgraphlogrevs().
graphlog: remove too early return from getgraphlogrevs() for empty repo
Even if repository is empty, null revision should exist.