Using 'global' is usually a bad sign. Here it is used so that one can empty the
content of a dict at the global scope. We '_terminfo_params.clear()' and
drop the global.
The 'hg debugcolor' command gains a '--style' flag to display all the configured
labels and their styles. This have many benefits:
* discovering documented label,
* checking consistency between label's style,
* showing the actual style of a label.
The previous ordering were provided by the set. The new output is more stable
and rational. In addition we have some logic to keep the '_background' version
together to help readability.
We are about to introduce a second mode for 'hg debugcolor' that would list the
known label and their configuration, so we split the code related to color and
effect out of the main function.
Before this change, running 'debugcolor' would destroy all color style for the
rest of the process life. We now properly backup and restore the variable
content. Using a global variable is sketchy in general and could probably be
removed. However, this is a quest for another adventure.
If terminfo mode is in effect, and an effect is used which is missing from
the terminfo database, simply silently ignore the request, leaving the
output unaffected rather than causing a crash.
If the entry in the terminfo database for your terminal is missing some
attributes, it should be possible to create them on the fly without
resorting to just making them a color. This change allows you to have
[color]
terminfo.<effect> = <code>
where <effect> might be something like "dim" or "bold", and <code> is the
escape sequence that would otherwise have come from a call to tigetstr().
If an escape character is needed, use "\E". Any such settings will
override attributes that are present in the terminfo database.
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 _
When code like filemerge._iprompt calls ui.prompt, it expects
the user to see the output in addition to getting the prompt.
Other code such as histedit may call ui.pushbuffer, but its
goal is not to interfere with prompts, so this commit adds
an optional prompt flag to ui.write and has _readline
include that argument.
ui.promptchoice calls ui.prompt which calls ui._readline.
This commit also updates hgext.color.write.
Instead of the mapping hack introduced by d4686e0c15c9, this patch changes the
way how a label symbol is evaluated. This is still hackish, but should be more
predictable in that it doesn't depend on the known color effects.
This change is intended to eliminate the reference to color._effects so that
color.templatelabel() can be merged with templater.label().
Since label() should return a string (or a thunk to be evaluated to a string),
this change is okay. This helps porting to evalstring() helper. See the next
patch for details.
Because labels are applied at write() time since ce03e7329682,
colorui.popbuffer() is useless and it doesn't update _bufferapplylabels
correctly. Removing it should fix the problem.
In many cases, we don't need to cast to a str because the object will
be cast when it is eventually written.
As part of testing this, I added some code to raise exceptions when a
non-str was passed in and wasn't able to trigger it. i.e. we're already
passing str into this function everywhere, so the casting isn't
necessary.
Previously, we stored 2-tuples of text and label in a list and then
evaluated the labels when the buffer was popped. After this patch,
we evaluate the labels at write time and do a simple join when the
buffer is popped.
This patch appears to have no impact on performance, despite creating
fewer 2-tuples and having fewer strings hanging around in memory.
Python 2.6 introduced the "except type as instance" syntax, replacing
the "except type, instance" syntax that came before. Python 3 dropped
support for the latter syntax. Since we no longer support Python 2.4 or
2.5, we have no need to continue supporting the "except type, instance".
This patch mass rewrites the exception syntax to be Python 2.6+ and
Python 3 compatible.
This patch was produced by running `2to3 -f except -w -n .`.
The previous patch made 'string' is always interpreted as a template. So
this patch removes the special handling of r'rawstring' instead. Now r''
disables template processing at all.
Retain old label as well for backwards compatibility.
Today, the terms 'active' and 'current' are interchangeably used throughout the
codebase in reference to the active bookmark (the bookmark that will be updated
with the next commit). This leads to confusion among developers and users.
This patch is part of a series to standardize the usage to 'active' throughout
the mercurial codebase and user interface.
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.
We want to capture hooks output during bundle2 processing. For this purpose we
introduce a new 'subproc' argument to 'ui.pushbuffer'. When set, the output of
sub process created through 'ui.system' will be captured in the buffer too.
This will be used in the next changeset.
When 'term' is None because it isn't in the environment, don't iterate over it.
Unfortunately, unsetting $TERM or exporting it as '' doesn't work in the tests,
so there's no way to simulate cmd.exe in the test suite.
This fixes a mild case of cut-and-paste code regarding failing to set
terminal modes. This is evident in the win32 comment that is misplaced
for the terminfo mode since cset 1456f081d00e.
Instead, we refactor this C&P into a small local function.
It's pretty annoying to be getting this warning when already the
colour extension has no hope of working. If there isn't a human on the
other end to to see the colours, there probably isn't a human either
who cares about this warning. More likely, some script somewhere is
gonna get confused with the warning output.
Of course, if we still want to see the warning for some reason, we can
always set --config ui.interactive=True.
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.
The current color mode detection on Windows assumes the presence of the
TERM environment variable assumes ANSI is supported. However, this isn't
always true. In MSYS (commonly found as part of MinGW), TERM is set to
"cygwin" and the auto resolved color mode of "ansi" results in escape
sequences getting printed literally to the terminal. The output is
very difficult to read and results in a bad user experience. A
workaround is to activate the pager and have it attend all commands (GNU
less in MSYS can render ANSI terminal sequences properly).
In Cygwin, TERM is set to "xterm." Furthermore, Cygwin supports
displaying these terminal sequences properly (unlike MSYS).
This patch changes the mode auto-detection logic on Windows to be more
conservative about selecting the "ansi" mode. We now only select the
"ansi" mode if TERM is set and it contains the string "xterm" or if
we were unable to talk to win32 APIs to determine the settings. There is
a chance this may take away "ansi" from a terminal that actually
supports it. The recourse for this would be to patch the detection to
act appropriately and to override color.mode until that patch has
landed. However, the author believes this regression is tolerable, since
it means MSYS users won't have gibberish printed by default.
Since MSYS's common pager (less) supports display of ANSI sequences,
there is room to patch the color extensions so it can select the ANSI
color mode if a pager is activated.
Mozilla (being an active user of MSYS) would really appreciate this
being part of the stable branch. However, since I believe it is BC, I
haven't explicitly requested application to stable since I figure that
request will be denied.
The current output is mostly a wall of text. This makes it hard to
actually check something for people with lazy eyes. We use labels and
colors to make it more joyful (and get the patch summaries to stand
out). The colors have been arbitrarily choosen. They can be changed
later if someone has a more scientific choice.
The color docstring was getting long. This splits it up into
bite-sized sections and rearranges the order of the paragraphs a
little to match these sections.
This is most noticeable when using custom templates. Before this
patch, a template like {label("foo.bar", baz)} would emit
[foo.bar|]
whenever baz was empty. This cset simply omits all output when baz is
empty.
This is a no-op change that simply suggests that tabs can be
colourised, but defaults to no colour effects for tabs. This
complements cset 56ff694317ca.
Like the similar effects for phases from 8f322ff11fbb, we set the
default effects to '' instead of None, so that this is a true noop
change. Otherwise, the diff.tab effect would override (i.e.
neutralise) the effect of the surrounding label.
It's very useful to be able to colourise csets according to their
phases. There was no indication anywhere in the docs that this is
possible.
We use e.g. `changeset.secret = ` instead of `changeset.secret
='none'`, because otherwise this is a BC: it would nullify the effects
given to log.changeset label that usually surrounds the
changeset.{phase} labels. Specifying the label without any effect
instead of 'none' is a true no-op change and purely documentation.
Before, the format was
label(labeled text) # single label
[label1 label2](labeled text) # multiple
Now, it's
[labels|labeled text]
..which should make things a bit more clear.
This is a debug option for showing labels. This can be helpful for
knowing which labels are available for colouring or to see the output
when defining your own templates. A couple of tests are included.
It is a deeply hidden secret that it's possible to colorise so many
things with so many different labels. This is an attempt to document
this. The text is a bit long, but it seems as short as can be while
documenting everything. Perhaps it should be hidden under a --verbose
option.
