The error only occured when Python didn't have curses - such as on Windows and
when Python was built without curses support.
No curses can also be emulated by (re)moving .../lib/python2.7/curses/ from the
Python installation.
It is left as an exercise to figure out exactly what changed in Mercurial that
triggered this error.
Previously, words like 'red' had to be protected by quotes before passing to
the label template function. Now, we add color effects to the symbol table so
that commands like,
$ hg log -r . -T "{label(red, node|short)}\n"
can work without the need for quoting.
Changeset c84f81c3e120 (released with 2.8.1) fixed "recursively
evaluate string literals as templates" problem (issue4103) by
introducing "_evalifliteral()".
But some parts in template expressions below are still processed by
the combination of "compiletemplate()" and "runtemplate()", and may
cause same problem unexpectedly.
- 'init' and 'hang' of 'fill(text, width, init, hang)'
- 'expr' of 'sub(pat, repl, expr)'
- 'label' of 'label(label, expr)'
This patch processes them by "_evalifliteral()" instead of the
combination of "compiletemplate()" and "runtemplate()" to avoid
recursive evaluation of string literals completely.
This extension saves shelved changes using a temporary draft commit,
and bundles the temporary commit and its draft ancestors, then
strips them.
This strategy makes it possible to use Mercurial's bundle and merge
machinery to resolve conflicts if necessary when unshelving, even
when the destination commit or its ancestors have been amended,
squashed, or evolved. (Once a change has been unshelved, its
associated unbundled commits are either rolled back or stripped.)
Storing the shelved change as a bundle also avoids the difficulty
that hidden commits would cause, of making it impossible to amend
the parent if it is a draft commits (a common scenario).
Although this extension shares its name and some functionality with
the third party hgshelve extension, it has little else in common.
Notably, the hgshelve extension shelves changes as unified diffs,
which makes conflict resolution a matter of finding .rej files and
conflict markers, and cleaning up the mess by hand.
We do not yet allow hunk-level choosing of changes to record.
Compared to the hgshelve extension, this is a small regression in
usability, but we hope to integrate that at a later point, once the
record machinery becomes more reusable and robust.
Previously, colorui assumed that it would only be called when mode wasn't
None. 255b770b2eff changed that, so now colorui needs to care about whether it
should colorize output.
Previously only the class of repo.ui was set. The class was set in the wrapper
of dispatch._runcommand. But this is called after the repo is created. Only
the class of repo.ui is set because repo.baseui already exists and is not
accessible.
We now set the class in uisetup because this is called before repo creation.
This is also the place suggested in the wiki for modifying classes.
less with the -R option only supports ANSI color codes, and terminfo
mode issue non-ANSI color codes (depending on the database). The -r
option can work around this, but there are users currently using the
-R option, and defaulting to terminfo would break colorization in less
for them without warning.
since it's possible to reuse the ui object (see 6772a32edec7)
between dispatch calls, the ui might have been wrapped already.
we could probably move this test up a bit but leaving it here
allows updates to take effect by extstyles() and configstyles().
Also restructures the mode determination as discussed on IRC.
I tried to simplify the code too, while keeping the original
semantics except for the case of --color=always.
This fixes the color extension not working with pager (broken in
cab5f9b68e3a). The pager extension already sets ui.formatted=True to
allow this use case.
Without this change, curses complains when invoked in certain contexts
because stdout isn't a tty (such as emacs integration) but we ask it
to check for various bits of information from terminfo.
Using terminfo instead of hard-coding ECMA-48 control sequences provides a
greater assurance that the terminal codes are correct for the current
terminal type; not everything supports the ANSI escape codes.
It also allows us to use a wider range of colors when a terminal emulator
supports it (such as 16- or 256-color xterm), and a few more non-color
attributes, such as the ever-popular blink.
This complicates the code a bit, since attributes need to be masked together
correctly before they are applied. Perhaps the code should be redesigned at
some point, but this works well for now.
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".
