Work in progress, pretty printer

[Roedy Green]

I have spend the last two weekends implementing one of my student
products:

http://mindprod.com/projjavapresenter.html

It takes pre-parsed Java source snippets, not necessarily
syntactically valid, and displays them in colours and fonts in a way
to make the meaning of the program more obvious.

For example, it highlights RETURNs, and boldens references in the
places they are defined.

I render with drawString paying attention to the clip region. Boy is
this fast!

I am still playing with the colourscheme to give maximal information
without sensory overload. I want the effects to be subtle, but
sufficiently distinct so you can tell what's a keyword, method,
variable, constant, Class, Interface just by looking at the word
without having to study the context.

I use variable size ()[] {} to make it easier to visually balance.

All the hard stuff is done. One more weekend, converting my website
to the new scheme, and working out macros to generate the <applet tags
and I should be there.

All I will have to do to post Java code on my website is put the
snippet in a special directory, and refer to it by name in my HTML
using a macro. That will generate an applet with just the right size
window (or scrolling window), to view the source. You can cut/paste
to cannibalise. For people without Java, they will have the option to
download the snippet as a *.java file.

 

[Andrew Thompson]

http://mindprod.com/projjavapresenter.html

Looks good Roedy, but I am curious as to
why you do not use stylesheets for _all_
the formatting? (I am referring to
the use of <b> and <br> tags)

The advantage to using pure CSS for styling is
that then it becomes easier for the user to
'tweak' the look to their own needs.

Another couple of questions.
Will it have an option to include line numbers?

What will you do with single line comments '//'*
and multi-line comments '/* .. */' **?
* <http://www.physci.org/launcher.jsp?class=/codes/AWT1/CardTest#26>
**
<http://www.physci.org/launcher.jsp?class=/codes/AnimateBalls/AnimateFrame#78>
[ It seems that particularly important things
are often mentioned in these comments.. ]

 

[Roedy Green]

Looks good Roedy, but I am curious as to
why you do not use stylesheets for _all_
the formatting? (I am referring to
the use of <b> and <br> tags)

The advantage to using pure CSS for styling is
that then it becomes easier for the user to
'tweak' the look to their own needs.

That project description is pretty old. My implementation does not use
HTML at all. I have documented how it works at
http://mindprod.com/projjavapresenter.html#JDISPLAY

I have been using HTML, but you notice problem with unwanted spaces
when long lines get broken in tidying. The program I have been using
JTOH is buggy and too complicated to fix. My new program does the
parsing in simpler passes.

In the scheme in place on my website now, I have tags like "jclassdef"
and "jclassref" which are defined as the same but jclassdef is bold.

 

[Roedy Green]

Another couple of questions.
Will it have an option to include line numbers?

That would be pretty easy to add.

 

[Roedy Green]

What will you do with single line comments '//'*
and multi-line comments '/* .. */' **?
* <http://www.physci.org/launcher.jsp?class=/codes/AWT1/CardTest#26>
**
<http://www.physci.org/launcher.jsp?class=/codes/AnimateBalls/AnimateFrame#78>
[ It seems that particularly important things
are often mentioned in these comments.. ]

I don't quite get what you are after.
do you want
/*
/**
/* multiline
//

rendered differently??

night now I have them rendered in green italic. It would not be hard
to make some finer distinctions.

 

[Andrew Thompson]

What will you do with single line comments '//'*
and multi-line comments '/* .. */' **? .....
[ It seems that particularly important things
are often mentioned in these comments.. ]

I don't quite get what you are after.
do you want
/*
/**
/* multiline
//

rendered differently??

In a nutshell, yes. JavaDoc comments are good
for describing the general layout of the program,
while the other two often highligh particular
'gotchas' the programmer faced and solved, or
warn against changing the code for z, y or z reason.