corinthia-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From jan i <>
Subject Re: Colo(u)rs?
Date Mon, 18 May 2015 08:14:17 GMT
On 18 May 2015 at 01:48, Gabriela Gibson <> wrote:

> I made (for my branch) a color.c and a color.h, which can be
> handy if you're looking at a wall of text and want to spot
> something in particular without straining your eyes too much.
> It's easy to use:
>  printf(MAGENTA "foo = %d" RESET, 5);
> will give you a nice 'foo = 5' magenta output.  There's also
> stuff like blue("bar") which can be stuffed into other string
> functions.
> I wrangled it so that this feature can be turned on with a -D
> switch at compile time, ie, in CmakeLists.txt you can do:
>   set(CMAKE_C_FLAGS "-std=c99 -D_GNU_SOURCE -g -fPIC -DCOLOR_ON=1")
> otherwise it's not going to show up.
> 1) Does anyone else other than me find this kind of thing useful?
I had not thought of it, but it is not a bad idea....just wonder where we
have output that benefit from coloring.

> 2) Is it portable?
I dont think so, for a number of reasons...I would not know how to do color
on a vt100 terminal in Linux or a dos prompt in windows.

> 3) If 1 & 2, would you enjoy this dev debugging feature being
> added?
Yes an no.

We should never use printf or similar in DocFormats, those are bound to
give problems in a number of cases.

I discussed earlier with Peter, the idea that we make some DEBUG_PRINT
macros. The macro should contain
an #ifdef DEBUG (or similar), but most importantly it should NOT do printf.

Instead it should print via a global function pointer (parameters like
printf). That way the main program can decide to use
printf or other functions (when we define the API, we will have a setup()
call, that could then included the function ptr.

Going down that road, would open up for LOG_PRINT, WARNING_PRINT,
INFO_PRINT as well.

I am very much for the MACROS, and against a direct printf. Colors is more
a portability concern.

jan i.

> G
> --
> Visit my Coding Diary:

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message