Oh, and on the main topic (of colours) - I suggest making it either a command-line option or an environment variable. Colours are great when viewing output on the terminal (and piping through less, you can pass it the -R command line option to have it preserve the colours), but sometimes if you want to redirect output to a file and then open it in an editor you might not want those control characters there.
As others have mentioned, I believe there may be compatibility problems with windows as well - hence using macros which can easily be placed inside #ifndef WINDOWS (with an empty alternative for windows) would be a good solution here. The other day I happened to watch part of the famous “BBS documentary” which talked about the fascinating ANSI art scene in the 80s & early 90s, and how part of the reason that ended up dying out was that it became harder to view ANSI files under windows - https://www.youtube.com/watch?v=2ReS4Bp4IPY I actually started using colour in this manner recently in a Python program I’m writing. Rather than have macros to turn it on or off, I defined functions to set a particular colour, add the string, then have the ANSI code to reset the colour: def magenta2(s): return '\033[1;95m'+str(s)+'\033[m’ In a C macro, this would probably be something like (not tested): #define magenta(s) "\033[1;95m” s "\033[m” and with the windows conditional definition: #ifdef WINDOWS #define magenta(s) s #else #define magenta(s) "\033[1;95m” s "\033[m” #endif — Dr Peter M. Kelly pmke...@apache.org PGP key: http://www.kellypmk.net/pgp-key <http://www.kellypmk.net/pgp-key> (fingerprint 5435 6718 59F0 DD1F BFA0 5E46 2523 BAA1 44AE 2966) > On 26 May 2015, at 5:13 am, Gabriela Gibson <gabriela.gib...@gmail.com> wrote: > > On Mon, May 18, 2015 at 9:14 AM, jan i <j...@apache.org> wrote: > >> On 18 May 2015 at 01:48, Gabriela Gibson <gabriela.gib...@gmail.com> >> wrote: >> >> >>> >>> 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. >> >> I find it useful for debugging when: > > 1) there is a lot of output. Looking for something blue is quicker than > reading it all. > > 2) If there is something that does not always occur and that may go under > in other output. > > > >>> >>> 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. >> >> Hmm, but I guess it would work on a cygwin xterm in windows or on a mac? > As in, partially portable? ;-) > > >>> >>> 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. >> > > That would be handy. It's also nice to be able to leave in debugging > statements sometimes and being able to turn just that suite on or off. > > >> I am very much for the MACROS, and against a direct printf. Colors is more >> a portability concern. >> > > I did some thinking today how to keep colour out of Corinthias' hair but > still be able to use it locally and had the idea that I should try and make > a dynamic library for the colors, so that I can easily use it everything I > do in C. I'm sure someone already wrote a RollsRoyce doing just the same > thing, but, it was fun nevertheless and a good reason to learn about the > topic. I am now proud owner of my very own /usr/local/lib/libcolor.so and > have started to use it -- profit! :> > > This together with Jan's debug print macros idea makes me think that maybe > there is already such a library of a good debug system out there we could > use, or, if there isn't, perhaps separating this kind of service out would > not be the worst thing to do -- having a great debug mechanism that I know > and that just works everywhere for me would be brill. > > G > > Ps.: Btw, it appears (if one is inclined to believe a Reddit meme!) that > the literal translation of the Chinese name for 'owl' is 'cat head eagle'. > > >> rgds >> jan i. >> >> >> >>> G >>> >>> -- >>> Visit my Coding Diary: http://gabriela-gibson.blogspot.com/ >>> >> > > > > -- > Visit my Coding Diary: http://gabriela-gibson.blogspot.com/
