This weekend I went ahead and studied the prettyprinter source code. Now I have a pretty good understanding of how the sections are generated and how each individual printable element is sent through the prettyprinter, making much of my original email irrelevant. With this new understanding in hand, I will go ahead and cleanup my old syntax highlighting code so that it is more systematic.
I also found out that the reason why M: effect pprint* is not being called by "see" is that the stack effect is being converted to a string and then directly dumped into the print tree via the "styled-text" word (using an italic font, which isn't even visible when the font is monospace). Would anyone mind if I changed this so that it calls M: effect pprint* instead? I am still curious about how to handle the whole UI theming aspect: 1) should things like "word-style" and "string-style" be moved into a new "prettyprinter.stylesheet" vocab? 2) should I add the Factor tans and dark slate blue colors to the rgb.txt file so that they can be easily reference using the COLOR: word? Or should I have an auxiliary, in-memory lookup table for these theme colors at parse time? 3) to what extent should I design for easy customization of the browser's syntax highlighting? As always, I would also love to get feedback about the visual direction that I am going in. I don't want to pursue a path that is not in line with the wishes of the core Factor community. -keith ------------------------------------------------------------------------------ Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
