On Fri, Dec 03 2010, Renaud AUBIN wrote:

I can either help or port if needed…

Yes, that would be really great!! Thank you! In the meantime, I'll work with an older version. (no time to learn lpeg now...) Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

Work in progress… I hope to deliver something operational at the end of this weekend or sometime in the next week. The "not-so-temporary" name is u-pretty-c.lua and u-pretty-c.mkiv according to Hans's recommandations: "Now, additional pretty printers can be plugged in as well (there is a register function for that) and can have names not starting with v-. Even better, they can be regular user modules, so in your case u-pretty-ra-xml.tex or so will do." FYI, the port of the previously submitted pret-xml.lua (now u-pretty-ra-xml, based on the new pp structure) is in progress… u-pretty-ra-xml is, in my POV, too complicated to be used as a decent use case to rewrite the wiki page related to Pretty Printing but u-pretty-c will certainly be a good candidate… Renaud Le 03/12/2010 22:38, Hans Hagen a écrit :

On 3-12-2010 10:31, Peter Münster wrote:

...

On Fri, Dec 03 2010, Renaud AUBIN wrote:

...

I can either help or port if needed…

Yes, that would be really great!! Thank you! In the meantime, I'll work with an older version. (no time to learn lpeg now...)

fyi: the name should be more explicit, like v-c-variant-xxx or so as the can be multiple solutions; the shorter v-*.lua and v-parsed-*.lua names are reserved for core lexers (on my agenda is to do some c lexing as part of cweb lexing) .

Hans

On Sun, Dec 05 2010, Renaud AUBIN wrote:

Peter: could you test it?

Hello Renaud, Yes, I've tested with my standard "test.tex" and it's really good, even more coloring than my pret-c.lua !

I let you add your copy(left) stuff

Why me?

and I will make a public git repo on gitorious if you agree.

Good idea (how could I disagree???). Many thanks for your efforts! Peter -- Contact information: http://pmrb.free.fr/contact/

On 5-12-2010 3:06, Renaud AUBIN wrote:

Ok, I have made a first version available as a Dropbox ressource: http://dl.dropbox.com/u/5289718/u-pretty-c.7z It certainly needs some improvements (I have some in mind since I have tested it on time.h ⇒ ouch). Feedbacks are welcome since I'll not use it intensively in a near future.

Peter: could you test it? I let you add your copy(left) stuff and I will make a public git repo on gitorious if you agree.

Hans: do you agree with the naming scheme and the copyright stuff before I put it on gitorious?

maybe better the name t-pretty-c is better, of if you follow some strategy t-pretty-emacs-c or so (if there are many variants possible) maybe you should protect the color names as for instance redefining darkred might not be the intention Hans ----------------------------------------------------------------- Hans Hagen | PRAGMA ADE Ridderstraat 27 | 8061 GH Hasselt | The Netherlands tel: 038 477 53 69 | voip: 087 875 68 74 | www.pragma-ade.com | www.pragma-pod.nl -----------------------------------------------------------------

20:40 nibua-r committed 9c5877c Color abstraction. 20:33 nibua-r committed 2a2a9e1 The test file now use t-pretty-c instead of u-pretty-c. 20:31 nibua-r committed 921eca5 u-pretty-c renamed to t-pretty-c as suggested by Hans. Colors are now protected using the C prefix. Concerning the color abstraction patch, one needs just to overload Ccomment, Cpreproc, Cstring, Ctype, Ckeyword, Cname and Cfuncnbound to use custom color scheme. Cheers, Renaud Le 06/12/2010 15:04, Peter Münster a écrit :

On Mon, Dec 06 2010, Hans Hagen wrote:

...

maybe better the name t-pretty-c is better, of if you follow some strategy t-pretty-emacs-c or so (if there are many variants possible)

The only thing in common with emacs, is the default color-scheme. You can get any variant just by changing the color setup. Peter

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 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, \c!style=]

I have not looked into the new verbatim code yet, but I have been thinking about a similar interface for a new module that uses external programs for syntax highlighting (sort of a superset of t-vim that will allow one to use other programs like pgyments, etc.). Why are you using a C prefix for all environments? Isn't it better to use a syntax like this: \startsetups[verbatim:C] \definestartstop[SnippetName][color=...,style=...] \definestartstop[string][color=...,style=...] .... \stopsetups and then pass setups=verbatim:C to an appropriate \setup... command. That will make it easy to share the same syntax highlighting between different languages. Aditya

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 Cfuncnbound to use custom color scheme.

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, \c!style=]

I have not looked into the new verbatim code yet, but I have been thinking about a similar interface for a new module that uses external programs for syntax highlighting (sort of a superset of t-vim that will allow one to use other programs like pgyments, etc.).

it all boils down hooking in a parser then:

\startluacode local function parser(s) local s = somexternalthing(s) -- feedback s end

visualizers.register("myparser", { parser = parser }) \stopluacode

\starttyping[option=myparser] .... \stoptyping

Thanks for the explanation. But, I am not too keen to write parsers on my own when I can easily borrow existing ones.

...

Why are you using a C prefix for all environments? Isn't it better to use a syntax like this:

\startsetups[verbatim:C] \definestartstop[SnippetName][color=...,style=...] \definestartstop[string][color=...,style=...] .... \stopsetups

and then pass setups=verbatim:C to an appropriate \setup... command. That will make it easy to share the same syntax highlighting between different languages.

it's hard to come up with common names for characteristics for all those languages

But it does allow you to choose a "color scheme" for pretty printing. This is similar to how most editors choose color schemes.

but at some point we can have a set predefined as default

btw, startstop can inherit (now):

\definestartstop [MetapostSnippet] [DefaultSnippet]

etc so there is no need for setups

Setups have an advantage that one does not pollute the cs names. After all, \DefaultSnippet is not useful outside the pretty printing region. An alternative could be to use a namsespace in define in all definitions, e.g., \definestartstop[visualizer::Snippet] On a related note, does it make sense to add foregroundcolor and foregroupdstyle keys to \definebar? (Then, bars will be an appropriate and versatile mechanism to define syntax highlighting regions). Aditya

On Tue, Dec 7, 2010 at 2:30 PM, Hans Hagen 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 your prog do do something with str and return the result end

OK. This sounds much easier than writing my own wrappers. I will try to port the t-vim module to use the new code. Aditya

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 darkred redefinition for example ;) )

I still don't understand. Where do you need to redefine darkred? Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/

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 \setupcolor[ema, x11, xwi] there are already a lot of predefined colors, so I don't think that you need new color definitions in the module. Peter -- Contact information: http://pmrb.free.fr/contact/

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 do inline typing: bla bla \typeC{int main(){}} bla bla The \definecolor[] lines (dirty workaround) were just copied from colo-ema.tex. The problem with the pretty-c.lua was, that color_init() was called at every \typeC{} or \startC. In your t-pretty-c.mkiv you can use \setupcolor[ema] without problems. Cheers, Peter -- Contact information: http://pmrb.free.fr/contact/