|
|
|
|
#ifndef COLOR_H
|
|
|
|
|
#define COLOR_H
|
|
|
|
|
|
|
|
|
|
struct strbuf;
|
|
|
|
|
|
|
|
|
|
/* 2 + (2 * num_attrs) + 8 + 1 + 8 + 'm' + NUL */
|
|
|
|
|
/* "\033[1;2;4;5;7;38;5;2xx;48;5;2xxm\0" */
|
|
|
|
|
/*
|
|
|
|
|
* The maximum length of ANSI color sequence we would generate:
|
|
|
|
|
* - leading ESC '[' 2
|
parse_color: recognize "no$foo" to clear the $foo attribute
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
10 years ago
|
|
|
* - attr + ';' 3 * 10 (e.g. "1;")
|
|
|
|
|
* - fg color + ';' 17 (e.g. "38;2;255;255;255;")
|
|
|
|
|
* - bg color + ';' 17 (e.g. "48;2;255;255;255;")
|
|
|
|
|
* - terminating 'm' NUL 2
|
|
|
|
|
*
|
|
|
|
|
* The above overcounts attr (we only use 5 not 8) and one semicolon
|
|
|
|
|
* but it is close enough.
|
|
|
|
|
*/
|
parse_color: recognize "no$foo" to clear the $foo attribute
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 <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
10 years ago
|
|
|
#define COLOR_MAXLEN 70
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* IMPORTANT: Due to the way these color codes are emulated on Windows,
|
|
|
|
|
* write them only using printf(), fprintf(), and fputs(). In particular,
|
|
|
|
|
* do not use puts() or write().
|
|
|
|
|
*/
|
|
|
|
|
#define GIT_COLOR_NORMAL ""
|
|
|
|
|
#define GIT_COLOR_RESET "\033[m"
|
|
|
|
|
#define GIT_COLOR_BOLD "\033[1m"
|
|
|
|
|
#define GIT_COLOR_RED "\033[31m"
|
|
|
|
|
#define GIT_COLOR_GREEN "\033[32m"
|
|
|
|
|
#define GIT_COLOR_YELLOW "\033[33m"
|
|
|
|
|
#define GIT_COLOR_BLUE "\033[34m"
|
|
|
|
|
#define GIT_COLOR_MAGENTA "\033[35m"
|
|
|
|
|
#define GIT_COLOR_CYAN "\033[36m"
|
|
|
|
|
#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"
|
|
|
|
|
#define GIT_COLOR_BG_RED "\033[41m"
|
|
|
|
|
#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"
|
|
|
|
|
|
|
|
|
|
/* 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>
14 years ago
|
|
|
/*
|
|
|
|
|
* 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
|
|
|
|
|
|
|
|
|
|
/* 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;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* 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;
|
|
|
|
|
|
|
|
|
|
/*
|
|
|
|
|
* Use the first one if you need only color config; the second is a convenience
|
|
|
|
|
* if you are just going to change to git_default_config, too.
|
|
|
|
|
*/
|
|
|
|
|
int git_color_config(const char *var, const char *value, void *cb);
|
|
|
|
|
int git_color_default_config(const char *var, const char *value, void *cb);
|
|
|
|
|
|
|
|
|
|
int git_config_colorbool(const char *var, const char *value);
|
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>
14 years ago
|
|
|
int want_color(int var);
|
|
|
|
|
int color_parse(const char *value, char *dst);
|
|
|
|
|
int color_parse_mem(const char *value, int len, char *dst);
|
|
|
|
|
__attribute__((format (printf, 3, 4)))
|
|
|
|
|
int color_fprintf(FILE *fp, const char *color, const char *fmt, ...);
|
|
|
|
|
__attribute__((format (printf, 3, 4)))
|
|
|
|
|
int color_fprintf_ln(FILE *fp, const char *color, const char *fmt, ...);
|
|
|
|
|
void color_print_strbuf(FILE *fp, const char *color, const struct strbuf *sb);
|
|
|
|
|
|
|
|
|
|
int color_is_nil(const char *color);
|
|
|
|
|
|
|
|
|
|
#endif /* COLOR_H */
|
