path: root/color.h
AgeCommit message (Collapse)Author
2018-08-13range-diff: use dim/bold cues to improve dual color modeJohannes Schindelin
It *is* a confusing thing to look at a diff of diffs. All too easy is it to mix up whether the -/+ markers refer to the "inner" or the "outer" diff, i.e. whether a `+` indicates that a line was added by either the old or the new diff (or both), or whether the new diff does something different than the old diff. To make things easier to process for normal developers, we introduced the dual color mode which colors the lines according to the commit diff, i.e. lines that are added by a commit (whether old, new, or both) are colored in green. In non-dual color mode, the lines would be colored according to the outer diff: if the old commit added a line, it would be colored red (because that line addition is only present in the first commit range that was specified on the command-line, i.e. the "old" commit, but not in the second commit range, i.e. the "new" commit). However, this dual color mode is still not making things clear enough, as we are looking at two levels of diffs, and we still only pick a color according to *one* of them (the outer diff marker is colored differently, of course, but in particular with deep indentation, it is easy to lose track of that outer diff marker's background color). Therefore, let's add another dimension to the mix. Still use green/red/normal according to the commit diffs, but now also dim the lines that were only in the old commit, and use bold face for the lines that are only in the new commit. That way, it is much easier not to lose track of, say, when we are looking at a line that was added in the previous iteration of a patch series but the new iteration adds a slightly different version: the obsolete change will be dimmed, the current version of the patch will be bold. At least this developer has a much easier time reading the range-diffs that way. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-08-13color: add the meta color GIT_COLOR_REVERSEJohannes Schindelin
This "color" simply reverts background and foreground. It will be used in the upcoming "dual color" mode of `git range-diff`, where we will reverse colors for the -/+ markers and the fragment headers of the "outer" diff. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-04-24color: introduce support for colorizing stderrJohannes Schindelin
So far, we only ever asked whether stdout wants to be colorful. In the upcoming patches, we will want to make push errors more prominent, which are printed to stderr, though. So let's refactor the want_color() function into a want_color_fd() function (which expects to be called with fd == 1 or fd == 2 for stdout and stderr, respectively), and then define the macro `want_color()` to use the want_color_fd() function. And then also add a macro `want_color_stderr()`, for convenience and for documentation. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2018-02-13color.h: document and modernize headerStefan Beller
Add documentation explaining the functions in color.h. While at it, migrate the function `color_set` into grep.c, where the only callers are. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2017-06-30diff.c: add dimming to moved line detectionStefan Beller
Any lines inside a moved block of code are not interesting. Boundaries of blocks are only interesting if they are next to another block of moved code. Signed-off-by: Stefan Beller <> Signed-off-by: Junio C Hamano <>
2016-07-11Merge branch 'js/color-on-windows-comment'Junio C Hamano
For a long time, we carried an in-code comment that said our colored output would work only when we use fprintf/fputs on Windows, which no longer is the case for the past few years. * js/color-on-windows-comment: color.h: remove obsolete comment about limitations on Windows
2016-07-11Merge branch 'jk/ansi-color'Junio C Hamano
The output coloring scheme learned two new attributes, italic and strike, in addition to existing bold, reverse, etc. * jk/ansi-color: color: support strike-through attribute color: support "italic" attribute color: allow "no-" for negating attributes color: refactor parse_attr add skip_prefix_mem helper doc: refactor description of color format color: fix max-size comment
2016-06-28color.h: remove obsolete comment about limitations on WindowsJohannes Schindelin
Originally, ANSI color sequences were supported on Windows only by overriding the printf() and fprintf() functions, as mentioned in e7821d7 (Add a notice that only certain functions can print color escape codes, 2009-11-27). As of eac14f8 (Win32: Thread-safe windows console output, 2012-01-14), however, this is no longer the case, as the ANSI color sequence support code needed to be replaced with a thread-safe version, one side effect being that stdout and stderr handled no matter which function is used to write to it. So let's just remove the comment that is now obsolete. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2016-06-23color: support strike-through attributeJeff King
This is the only remaining attribute that is commonly supported (at least by xterm) that we don't support. Let's add it for completeness. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-23color: support "italic" attributeJeff King
We already support bold, underline, and similar attributes. Let's add italic to the mix. According to the Wikipedia page on ANSI colors, this attribute is "not widely supported", but it does seem to work on my xterm. We don't have to bump the maximum color size because we were already over-allocating it (but we do adjust the comment appropriately). Requested-by: Simon Courtois <> Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2016-06-23color: fix max-size commentJeff King
We use fixed-size buffers for colors, because we know our parsing cannot grow beyond a particular bound. However, our comment description has two issues: 1. It has the description in two forms: a short one, and one with more explanation. Over time the latter has been updated, but the former has not. Let's just drop the short one (after making sure everything it says is in the long one). 2. As of ff40d18 (parse_color: recognize "no$foo" to clear the $foo attribute, 2014-11-20), the per-attribute size bumped to "3" (because "nobold" is actually "21;"). But that's not quite enough, as somebody may use both "bold" and "nobold", requiring 5 characters. This wasn't a problem for the final count, because we over-estimated in other ways, but let's clarify how we got to the final number. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2015-10-05color: add color_set helper for copying raw colorsJeff King
To set up default colors, we sometimes strcpy() from the default string literals into our color buffers. This isn't a bug (assuming the destination is COLOR_MAXLEN bytes), but makes it harder to audit the code for problematic strcpy calls. Let's introduce a color_set which copies under the assumption that there are COLOR_MAXLEN bytes in the destination (of course you can call it on a smaller buffer, so this isn't providing a huge amount of safety, but it's more convenient than calling xsnprintf yourself). Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-20parse_color: recognize "no$foo" to clear the $foo attributeJeff King
You can turn on ANSI text attributes like "reverse" by putting "reverse" in your color spec. However, you cannot ask to turn reverse off. For common cases, this does not matter. You would turn on "reverse" at the start of a colored section, and then clear all attributes with a "reset". However, you may wish to turn on some attributes, then selectively disable others. For example: git log --format="%C(bold ul yellow)%h%C(noul) %s" underlines just the hash, but without the need to re-specify the rest of the attributes. This can also help third-party programs, like contrib/diff-highlight, that want to turn some attribute on/off without disrupting existing coloring. Note that some attribute specifications are probably nonsensical (e.g., "bold nobold"). We do not bother to flag such constructs, and instead let the terminal sort it out. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-11-20parse_color: support 24-bit RGB valuesJeff King
Some terminals (like XTerm) allow full 24-bit RGB color specifications using an extension to the regular ANSI color scheme. Let's allow users to specify hex RGB colors, enabling the all-important feature of hot pink ref decorations: git log --format="%h%C(#ff69b4)%d%C(reset) %s" Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2014-10-14color_parse: do not mention variable name in error messageJeff King
Originally the color-parsing function was used only for config variables. It made sense to pass the variable name so that the die() message could be something like: $ git -c color.branch.plain=bogus branch fatal: bad color value 'bogus' for variable 'color.branch.plain' These days we call it in other contexts, and the resulting error messages are a little confusing: $ git log --pretty='%C(bogus)' fatal: bad color value 'bogus' for variable '--pretty format' $ git config --get-color bogus fatal: bad color value 'bogus' for variable 'command line' This patch teaches color_parse to complain only about the value, and then return an error code. Config callers can then propagate that up to the config parser, which mentions the variable name. Other callers can provide a custom message. After this patch these three cases now look like: $ git -c color.branch.plain=bogus branch error: invalid color value: bogus fatal: unable to parse 'color.branch.plain' from command-line config $ git log --pretty='%C(bogus)' error: invalid color value: bogus fatal: unable to parse --pretty format $ git config --get-color bogus error: invalid color value: bogus fatal: unable to parse default color value Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-19want_color: automatically fallback to color.uiJeff King
All of the "do we want color" flags default to -1 to indicate that we don't have any color configured. This value is handled in one of two ways: 1. In porcelain, we check early on whether the value is still -1 after reading the config, and set it to the value of color.ui (which defaults to 0). 2. In plumbing, it stays untouched as -1, and want_color defaults it to off. This works fine, but means that every porcelain has to check and reassign its color flag. Now that want_color gives us a place to put this check in a single spot, we can do that, simplifying the calling code. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-19diff: don't load color config in plumbingJeff King
The diff config callback is split into two functions: one which loads "ui" config, and one which loads "basic" config. The former chains to the latter, as the diff UI config is a superset of the plumbing config. The color.diff variable is only loaded in the UI config. However, the basic config actually chains to git_color_default_config, which loads color.ui. This doesn't actually cause any bugs, because the plumbing diff code does not actually look at the value of color.ui. However, it is somewhat nonsensical, and it makes it difficult to refactor the color code. It probably came about because there is no git_color_config to load only color config, but rather just git_color_default_config, which loads color config and chains to git_default_config. This patch splits out the color-specific portion of git_color_default_config so that the diff UI config can call it directly. This is perhaps better explained by the chaining of callbacks. Before we had: git_diff_ui_config -> git_diff_basic_config -> git_color_default_config -> git_default_config Now we have: git_diff_ui_config -> git_color_config -> git_diff_basic_config -> git_default_config Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-19color: delay auto-color decision until point of useJeff King
When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-08-18git_config_colorbool: refactor stdout_is_tty handlingJeff King
Usually this function figures out for itself whether stdout is a tty. However, it has an extra parameter just to allow git-config to override the auto-detection for its --get-colorbool option. Instead of an extra parameter, let's just use a global variable. This makes calling easier in the common case, and will make refactoring the colorbool code much simpler. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2011-04-05Share color list between graph and show-branchDan McGee
This also adds the new colors to show-branch that were added a while back for graph output. Signed-off-by: Dan McGee <> Signed-off-by: Junio C Hamano <>
2011-03-08wt-status: add helpers for printing wt-status linesJonathan Nieder
Introduce status_printf{,_ln,_more} wrapper functions around color_vfprintf() which take care of adding "#" to the beginning of status lines automatically. The semantics: - status_printf() is just like color_fprintf() but it adds a "# " at the beginning of each line of output; - status_printf_ln() is a convenience function that additionally adds "\n" at the end; - status_printf_more() is a variant of status_printf() used to continue lines that have already started. It suppresses the "#" at the beginning of the first line. Helped-by: Junio C Hamano <> Signed-off-by: Jonathan Nieder <> Signed-off-by: Junio C Hamano <>
2010-12-10default color.status.branch to "same as header"Jeff King
This gives it the same behavior as we had prior to 1d28232 (status: show branchname with a configurable color). To do this we need the concept of a "NIL" color, which is provided by color.[ch]. The implementation is very simple; in particular, there are no precautions taken against code accidentally printing the NIL. This should be fine in practice because: 1. You can't input a NIL color in the config, so it must come from the in-code defaults. Which means it is up the client code to handle the NILs it defines. 2. If we do ever print a NIL, it will be obvious what the problem is, and the bug can be fixed. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2010-04-14diff: add --word-diff option that generalizes --color-wordsThomas Rast
This teaches the --color-words engine a more general interface that supports two new modes: * --word-diff=plain, inspired by the 'wdiff' utility (most similar to 'wdiff -n <old> <new>'): uses delimiters [-removed-] and {+added+} * --word-diff=porcelain, which generates an ad-hoc machine readable format: - each diff unit is prefixed by [-+ ] and terminated by newline as in unified diff - newlines in the input are output as a line consisting only of a tilde '~' Both of these formats still support color if it is enabled, using it to highlight the differences. --color-words becomes a synonym for --word-diff=color, which is the color-only format. Also adds some compatibility/convenience options. Thanks to Junio C Hamano and Miles Bader for good ideas. Signed-off-by: Thomas Rast <> Signed-off-by: Junio C Hamano <>
2010-03-20Merge branch 'ml/color-grep'Junio C Hamano
* ml/color-grep: grep: Colorize selected, context, and function lines grep: Colorize filename, line number, and separator Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*
2010-03-20Merge branch 'jc/color-attrs'Junio C Hamano
* jc/color-attrs: color: allow multiple attributes
2010-03-07color: allow multiple attributesJunio C Hamano
In configuration files (and "git config --color" command line), we supported one and only one attribute after foreground and background color. Accept combinations of attributes, e.g. [diff.color] old = red reverse bold Signed-off-by: Junio C Hamano <>
2010-03-07Add GIT_COLOR_BOLD_* and GIT_COLOR_BG_*Mark Lodato
Add GIT_COLOR_BOLD_* macros to set both bold and the color in one sequence. This saves two characters of output ("ESC [ m", minus ";") and makes the code more readable. Add the remaining GIT_COLOR_BG_* macros to make the list complete. The white and black colors are not included since they look bad on most terminals. Signed-off-by: Mark Lodato <> Signed-off-by: Junio C Hamano <>
2009-11-27Add a notice that only certain functions can print color escape codesJohannes Sixt
We emulate color escape codes on Windows by overriding printf, fprintf, and fputs. Warn developers that these are the only functions that can be used to print them. Signed-off-by: Johannes Sixt <> Signed-off-by: Junio C Hamano <>
2009-11-16Check the format of more printf-type functionsTarmigan Casebolt
We already have these checks in many printf-type functions that have prototypes which are in header files. Add these same checks to some more prototypes in header functions and to static functions in .c files. cc: Miklos Vajna <> Signed-off-by: Tarmigan Casebolt <> Signed-off-by: Junio C Hamano <>
2009-04-14graph API: Added logic for colored edgesAllan Caffee
Modified the graph drawing logic to colorize edges based on parent-child relationships similiarly to gitk. Signed-off-by: Allan Caffee <> Signed-off-by: Junio C Hamano <>
2009-02-14Clean up use of ANSI color sequencesArjen Laarhoven
Remove the literal ANSI escape sequences and replace them by readable constants. Signed-off-by: Arjen Laarhoven <> Signed-off-by: Junio C Hamano <>
2009-01-26Merge branch 'js/diff-color-words'Junio C Hamano
* js/diff-color-words: Change the spelling of "wordregex". color-words: Support diff.wordregex config option color-words: make regex configurable via attributes color-words: expand docs with precise semantics color-words: enable REG_NEWLINE to help user color-words: take an optional regular expression describing words color-words: change algorithm to allow for 0-character word boundaries color-words: refactor word splitting and use ALLOC_GROW() Add color_fwrite_lines(), a function coloring each line individually
2009-01-18color: make it easier for non-config to parse color specsJeff King
We have very featureful color-parsing routines which are used for color.diff.* and other options. Let's make it easier to use those routines from other parts of the code. This patch adds a color_parse_mem() helper function which takes a length-bounded string instead of a NUL-terminated one. While the helper is only a few lines long, it is nice to abstract this out so that: - callers don't forget to free() the temporary buffer - right now, it is implemented in terms of color_parse(). But it would be more efficient to reverse this and implement color_parse in terms of color_parse_mem. This also changes the error string for an invalid color not to mention the word "config", since it is not always appropriate (and when it is, the context is obvious since the offending config variable is given). Finally, while we are in the area, we clean up the parameter names in the declaration of color_parse; the var and value parameters were reversed from the actual implementation. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>
2009-01-17Add color_fwrite_lines(), a function coloring each line individuallyJohannes Schindelin
We have to set the color before every line and reset it before every newline. Add a function color_fwrite_lines() which does that for us. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2008-05-14Provide git_config with a callback-data parameterJohannes Schindelin
git_config() only had a function parameter, but no callback data parameter. This assumes that all callback functions only modify global variables. With this patch, every callback gets a void * parameter, and it is hoped that this will help the libification effort. Signed-off-by: Johannes Schindelin <> Signed-off-by: Junio C Hamano <>
2008-02-18Add color.ui variable which globally enables colorization if setMatthias Kestenholz
Signed-off-by: Matthias Kestenholz <> Signed-off-by: Junio C Hamano <>
2007-12-06git config --get-colorboolJunio C Hamano
This adds an option to help scripts find out color settings from the configuration file. git config --get-colorbool color.diff inspects color.diff variable, and exits with status 0 (i.e. success) if color is to be used. It exits with status 1 otherwise. If a script wants "true"/"false" answer to the standard output of the command, it can pass an additional boolean parameter to its command line, telling if its standard output is a terminal, like this: git config --get-colorbool color.diff true When called like this, the command outputs "true" to its standard output if color is to be used (i.e. "color.diff" says "always", "auto", or "true"), and "false" otherwise. Signed-off-by: Junio C Hamano <>
2007-09-19Enable wt-status output to a given FILE pointer.Kristian Høgsberg
Still defaults to stdout, but you can now override wt_status.fp after calling wt_status_prepare(). Signed-off-by: Kristian Høgsberg <> Signed-off-by: Junio C Hamano <>
2006-09-08Move color option parsing out of diff.c and into color.[ch]Jeff King
The intent is to lib-ify colorizing code so it can be reused. Signed-off-by: Jeff King <> Signed-off-by: Junio C Hamano <>