Re: [NTG-context] colors for pretty-printing

2010-12-10 Thread Renaud AUBIN
I need to not redefine. Quoting Hans: maybe you should protect the color names as for instance redefining darkred might not be the intention In fact, I just need to find unique names for my colors to not overload the existing ones… Renaud I still don't understand. Where do you need to

Re: [NTG-context] colors for pretty-printing

2010-12-10 Thread Peter Münster
On Wed, Dec 08 2010, Renaud AUBIN wrote: In fact, I just need to find unique names for my colors to not overload the existing ones… \doifcolorelse{new funny color} {Error: funny color already exists!} {\definecolor[new funny color][...]} With \setupcolor[ema] or

Re: [NTG-context] colors for pretty-printing

2010-12-10 Thread Renaud AUBIN
Ok but then why did you define a specific color palet? local function color_init() color = 0 local def_colors = -- \setupcolor[ema] introduces new line... \\definecolor [darkred] [r=.545098] .. \\definecolor [orchid][r=.854902,g=.439216,b=.839216] ..

Re: [NTG-context] colors for pretty-printing

2010-12-10 Thread Peter Münster
On Fri, Dec 10 2010, Renaud AUBIN wrote: Ok but then why did you define a specific color palet? local function color_init() color = 0 local def_colors = -- \setupcolor[ema] introduces new line... The comment says it: \setupcolor[ema] introduces new line and that's annoying when you

Re: [NTG-context] colors for pretty-printing

2010-12-10 Thread Renaud AUBIN
Done and committed on http://gitorious.org/c-pretty-printer-module-for-context-mark-iv In your t-pretty-c.mkiv you can use \setupcolor[ema] without problems. ___ If your question is of interest to others as well,

Re: [NTG-context] colors for pretty-printing (was: Re: pret-c.lua - v-c.lua)

2010-12-07 Thread Aditya Mahajan
On Tue, 7 Dec 2010, Peter Münster wrote: On Mon, Dec 06 2010, Renaud AUBIN wrote: Concerning the color abstraction patch, one needs just to overload Ccomment, Cpreproc, Cstring, Ctype, Ckeyword, Cname and Cfuncnbound to use custom color scheme. You don't need that. There is already a

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Hans Hagen
On 7-12-2010 2:29, Aditya Mahajan wrote: On Tue, 7 Dec 2010, Peter Münster wrote: On Mon, Dec 06 2010, Renaud AUBIN wrote: Concerning the color abstraction patch, one needs just to overload Ccomment, Cpreproc, Cstring, Ctype, Ckeyword, Cname and Cfuncnbound to use custom color scheme. You

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Aditya Mahajan
On Tue, 7 Dec 2010, Hans Hagen wrote: On 7-12-2010 2:29, Aditya Mahajan wrote: On Tue, 7 Dec 2010, Peter Münster wrote: On Mon, Dec 06 2010, Renaud AUBIN wrote: Concerning the color abstraction patch, one needs just to overload Ccomment, Cpreproc, Cstring, Ctype, Ckeyword, Cname and

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Hans Hagen
On 7-12-2010 6:57, Aditya Mahajan wrote: Thanks for the explanation. But, I am not too keen to write parsers on my own when I can easily borrow existing ones. sure, but a simple one can be: function myparser(str) .. call your prog do do something with str and return the result end But it

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Renaud AUBIN
You don't need that. There is already a standard interface for color and style configuration. Example: \setupstartstop[CSnippetComment][color=blue] So you can simplify t-pretty-c.mkiv: \unprotect \setupcolor[ema] \definestartstop [CSnippetName] [\c!color=darkgoldenrod,

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Peter Münster
On Tue, Dec 07 2010, Renaud AUBIN wrote: So you can simplify t-pretty-c.mkiv: \unprotect \setupcolor[ema] \definestartstop [CSnippetName] [\c!color=darkgoldenrod, \c!style=] and so on... OK, but anyway, I have to protect the color names (to prevent

Re: [NTG-context] colors for pretty-printing

2010-12-07 Thread Aditya Mahajan
On Tue, Dec 7, 2010 at 2:30 PM, Hans Hagen pra...@wxs.nl wrote: On 7-12-2010 6:57, Aditya Mahajan wrote: Thanks for the explanation. But, I am not too keen to write parsers on my own when I can easily borrow existing ones. sure, but a simple one can be: function myparser(str)  .. call