2006-09-08 16:03:18 +08:00
|
|
|
#ifndef COLOR_H
|
|
|
|
|
#define COLOR_H
|
|
|
|
|
|
2011-02-26 13:09:41 +08:00
|
|
|
struct strbuf;
|
|
|
|
|
|
2010-02-28 10:56:38 +08:00
|
|
|
/*
|
|
|
|
|
* The maximum length of ANSI color sequence we would generate:
|
|
|
|
|
* - leading ESC '[' 2
|
2021-10-26 09:03:47 +08:00
|
|
|
* - reset ';' .................1
|
color: fix max-size comment
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24 01:31:44 +08:00
|
|
|
* - attr + ';' 2 * num_attr (e.g. "1;")
|
|
|
|
|
* - no-attr + ';' 3 * num_attr (e.g. "22;")
|
2014-11-20 23:25:39 +08:00
|
|
|
* - fg color + ';' 17 (e.g. "38;2;255;255;255;")
|
|
|
|
|
* - bg color + ';' 17 (e.g. "48;2;255;255;255;")
|
2010-02-28 10:56:38 +08:00
|
|
|
* - terminating 'm' NUL 2
|
|
|
|
|
*
|
color: fix max-size comment
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-24 01:31:44 +08:00
|
|
|
* The above overcounts by one semicolon but it is close enough.
|
|
|
|
|
*
|
|
|
|
|
* The space for attributes is also slightly overallocated, as
|
|
|
|
|
* the negation for some attributes is the same (e.g., nobold and nodim).
|
2016-06-24 01:39:07 +08:00
|
|
|
*
|
2016-06-24 01:40:16 +08:00
|
|
|
* We allocate space for 7 attributes.
|
2010-02-28 10:56:38 +08:00
|
|
|
*/
|
2016-06-24 01:40:16 +08:00
|
|
|
#define COLOR_MAXLEN 75
|
2006-09-08 16:03:18 +08:00
|
|
|
|
2009-02-14 05:53:40 +08:00
|
|
|
#define GIT_COLOR_NORMAL ""
|
|
|
|
|
#define GIT_COLOR_RESET "\033[m"
|
|
|
|
|
#define GIT_COLOR_BOLD "\033[1m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_BLACK "\033[30m"
|
2009-02-14 05:53:40 +08:00
|
|
|
#define GIT_COLOR_RED "\033[31m"
|
|
|
|
|
#define GIT_COLOR_GREEN "\033[32m"
|
|
|
|
|
#define GIT_COLOR_YELLOW "\033[33m"
|
|
|
|
|
#define GIT_COLOR_BLUE "\033[34m"
|
2009-04-14 03:53:41 +08:00
|
|
|
#define GIT_COLOR_MAGENTA "\033[35m"
|
2009-02-14 05:53:40 +08:00
|
|
|
#define GIT_COLOR_CYAN "\033[36m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_WHITE "\033[37m"
|
2021-10-26 06:32:36 +08:00
|
|
|
#define GIT_COLOR_DEFAULT "\033[39m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_BOLD_BLACK "\033[1;30m"
|
2010-03-08 00:52:45 +08:00
|
|
|
#define GIT_COLOR_BOLD_RED "\033[1;31m"
|
|
|
|
|
#define GIT_COLOR_BOLD_GREEN "\033[1;32m"
|
|
|
|
|
#define GIT_COLOR_BOLD_YELLOW "\033[1;33m"
|
|
|
|
|
#define GIT_COLOR_BOLD_BLUE "\033[1;34m"
|
|
|
|
|
#define GIT_COLOR_BOLD_MAGENTA "\033[1;35m"
|
|
|
|
|
#define GIT_COLOR_BOLD_CYAN "\033[1;36m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_BOLD_WHITE "\033[1;37m"
|
2021-10-26 06:32:36 +08:00
|
|
|
#define GIT_COLOR_BOLD_DEFAULT "\033[1;39m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_FAINT_BLACK "\033[2;30m"
|
range-diff: use dim/bold cues to improve dual color mode
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 <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-13 19:33:32 +08:00
|
|
|
#define GIT_COLOR_FAINT_RED "\033[2;31m"
|
|
|
|
|
#define GIT_COLOR_FAINT_GREEN "\033[2;32m"
|
|
|
|
|
#define GIT_COLOR_FAINT_YELLOW "\033[2;33m"
|
|
|
|
|
#define GIT_COLOR_FAINT_BLUE "\033[2;34m"
|
|
|
|
|
#define GIT_COLOR_FAINT_MAGENTA "\033[2;35m"
|
|
|
|
|
#define GIT_COLOR_FAINT_CYAN "\033[2;36m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_FAINT_WHITE "\033[2;37m"
|
2021-10-26 06:32:36 +08:00
|
|
|
#define GIT_COLOR_FAINT_DEFAULT "\033[2;39m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_BG_BLACK "\033[40m"
|
2009-02-14 05:53:40 +08:00
|
|
|
#define GIT_COLOR_BG_RED "\033[41m"
|
2010-03-08 00:52:45 +08:00
|
|
|
#define GIT_COLOR_BG_GREEN "\033[42m"
|
|
|
|
|
#define GIT_COLOR_BG_YELLOW "\033[43m"
|
|
|
|
|
#define GIT_COLOR_BG_BLUE "\033[44m"
|
|
|
|
|
#define GIT_COLOR_BG_MAGENTA "\033[45m"
|
|
|
|
|
#define GIT_COLOR_BG_CYAN "\033[46m"
|
2021-10-26 06:32:35 +08:00
|
|
|
#define GIT_COLOR_BG_WHITE "\033[47m"
|
2021-10-26 06:32:36 +08:00
|
|
|
#define GIT_COLOR_BG_DEFAULT "\033[49m"
|
2017-07-01 04:53:09 +08:00
|
|
|
#define GIT_COLOR_FAINT "\033[2m"
|
|
|
|
|
#define GIT_COLOR_FAINT_ITALIC "\033[2;3m"
|
2018-08-13 19:33:19 +08:00
|
|
|
#define GIT_COLOR_REVERSE "\033[7m"
|
2009-02-14 05:53:40 +08:00
|
|
|
|
2010-12-10 01:27:08 +08:00
|
|
|
/* A special value meaning "no color selected" */
|
|
|
|
|
#define GIT_COLOR_NIL "NIL"
|
|
|
|
|
|
color: delay auto-color decision until point of use
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-18 13:04:23 +08:00
|
|
|
/*
|
|
|
|
|
* The first three are chosen to match common usage in the code, and what is
|
|
|
|
|
* returned from git_config_colorbool. The "auto" value can be returned from
|
|
|
|
|
* config_colorbool, and will be converted by want_color() into either 0 or 1.
|
|
|
|
|
*/
|
|
|
|
|
#define GIT_COLOR_UNKNOWN -1
|
|
|
|
|
#define GIT_COLOR_NEVER 0
|
|
|
|
|
#define GIT_COLOR_ALWAYS 1
|
|
|
|
|
#define GIT_COLOR_AUTO 2
|
|
|
|
|
|
2011-04-05 13:40:23 +08:00
|
|
|
/* A default list of colors to use for commit graphs and show-branch output */
|
|
|
|
|
extern const char *column_colors_ansi[];
|
|
|
|
|
extern const int column_colors_ansi_max;
|
2008-02-18 15:26:03 +08:00
|
|
|
|
2011-08-18 13:03:48 +08:00
|
|
|
/*
|
|
|
|
|
* Generally the color code will lazily figure this out itself, but
|
|
|
|
|
* this provides a mechanism for callers to override autodetection.
|
|
|
|
|
*/
|
|
|
|
|
extern int color_stdout_is_tty;
|
|
|
|
|
|
2023-06-29 03:26:20 +08:00
|
|
|
/* Parse color config. */
|
2011-08-18 13:05:08 +08:00
|
|
|
int git_color_config(const char *var, const char *value, void *cb);
|
2008-02-18 15:26:03 +08:00
|
|
|
|
2015-09-25 05:08:21 +08:00
|
|
|
/*
|
2018-02-13 09:41:30 +08:00
|
|
|
* Parse a config option, which can be a boolean or one of
|
|
|
|
|
* "never", "auto", "always". Return a constant of
|
|
|
|
|
* GIT_COLOR_NEVER for "never" or negative boolean,
|
|
|
|
|
* GIT_COLOR_ALWAYS for "always" or a positive boolean,
|
|
|
|
|
* and GIT_COLOR_AUTO for "auto".
|
2015-09-25 05:08:21 +08:00
|
|
|
*/
|
2011-08-18 13:03:48 +08:00
|
|
|
int git_config_colorbool(const char *var, const char *value);
|
2018-02-13 09:41:30 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Return a boolean whether to use color, where the argument 'var' is
|
|
|
|
|
* one of GIT_COLOR_UNKNOWN, GIT_COLOR_NEVER, GIT_COLOR_ALWAYS, GIT_COLOR_AUTO.
|
|
|
|
|
*/
|
2018-04-21 18:09:57 +08:00
|
|
|
int want_color_fd(int fd, int var);
|
|
|
|
|
#define want_color(colorbool) want_color_fd(1, (colorbool))
|
|
|
|
|
#define want_color_stderr(colorbool) want_color_fd(2, (colorbool))
|
2018-02-13 09:41:30 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Translate a Git color from 'value' into a string that the terminal can
|
|
|
|
|
* interpret and store it into 'dst'. The Git color values are of the form
|
|
|
|
|
* "foreground [background] [attr]" where fore- and background can be a color
|
2024-05-02 19:03:31 +08:00
|
|
|
* name ("red"), a RGB code (#FF0000 or #F00) or a 256-color-mode from the
|
|
|
|
|
* terminal.
|
2018-02-13 09:41:30 +08:00
|
|
|
*/
|
2014-10-08 03:33:09 +08:00
|
|
|
int color_parse(const char *value, char *dst);
|
|
|
|
|
int color_parse_mem(const char *value, int len, char *dst);
|
2018-02-13 09:41:30 +08:00
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Output the formatted string in the specified color (and then reset to normal
|
|
|
|
|
* color so subsequent output is uncolored). Omits the color encapsulation if
|
|
|
|
|
* `color` is NULL. The `color_fprintf_ln` prints a new line after resetting
|
|
|
|
|
* the color. The `color_print_strbuf` prints the contents of the given
|
|
|
|
|
* strbuf (BUG: but only up to its first NUL character).
|
|
|
|
|
*/
|
2009-11-15 05:33:13 +08:00
|
|
|
__attribute__((format (printf, 3, 4)))
|
2007-09-18 08:06:42 +08:00
|
|
|
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
|
2009-11-15 05:33:13 +08:00
|
|
|
__attribute__((format (printf, 3, 4)))
|
2007-09-18 08:06:42 +08:00
|
|
|
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
|
2011-02-26 13:09:41 +08:00
|
|
|
void color_print_strbuf(FILE *fp, const char *color, const struct strbuf *sb);
|
2006-09-08 16:03:18 +08:00
|
|
|
|
2018-02-13 09:41:30 +08:00
|
|
|
/*
|
|
|
|
|
* Check if the given color is GIT_COLOR_NIL that means "no color selected".
|
|
|
|
|
* The caller needs to replace the color with the actual desired color.
|
|
|
|
|
*/
|
2010-12-10 01:27:08 +08:00
|
|
|
int color_is_nil(const char *color);
|
|
|
|
|
|
2006-09-08 16:03:18 +08:00
|
|
|
#endif /* COLOR_H */
|
