[cfe-dev] -emit-html example

[Argiris Kirtzidis]

Hi Ted,

Ted Kremenek wrote:
>
> I took a look at this patch.  I like the low-level refactorings to the 
> HTML rewriter API (e.g., adding HighlightKeyword).  This provides some 
> nice cleanups that simplify the conceptual complexity of the code 
> (particularly in SyntaxHighlight).  These aren't strictly necessary, 
> but do but some structure into how we want to name HTML classes for 
> span tags, etc.
>
> While I appreciate it's clean design, I have to be honest that I'm not 
> really sold (yet) on the Annotator class.  While I can envision that 
> we will have multiple clients of the HTML rewriter (e.g., the HTML 
> pretty-printer, the HTMLDiagnostics used by the static analysis 
> engine, a doxygen-like documentation generator, and so on) these 
> different clients will not necessarily fall into an ASTConsumer model, 
> nor will this interface necessarily be the one they want.
>
> Basically I'm not certain if it really solves a problem at this point, 
> and right now adds an extra abstraction layer to implement the 
> HTMLPrinter (something at its heart is very, very simple).  Right now 
> we have two clients of the HTML Rewriter: one is an ASTConsumer, and 
> the other is not.  I don't believe that an IDE would be an ASTConsumer 
> (in the clang driver sense) either, but would rather interact with the 
> clang libraries interactively to regenerate ASTs on-the-fly.
>
> The nice thing about the "low-level" APIs in HTMLRewrite.h is that 
> they make little assumption about the target application, but do the 
> lion's share of the work when pretty-printing code to HTML without 
> introducing an abstraction layer.  The result is that for the current 
> clients of the HTML Rewrite API (HTMLPrinter and HTMLDiagnostics) the 
> amount of code they do to perform HTML "tweaking" is small.  The 
> HTMLPrinter has about 20-30 lines of code (which includes opening 
> files and comments) and HTMLDiagnostics contains a little code for 
> doing HTML work but this is proportional to the extra stuff that it 
> outputs.
>
> Don't get me wrong; I'm a big believer in refactoring and modular 
> design.  I don't think the Annotator has a bad design, I just don't 
> think it's necessary at this point, and I'd rather not add more 
> abstraction unless its a clear benefit.

My motivation to propose the Annotator lib wasn't specifically to apply 
it for HTMLPrinter, that was more like an example.
The Annotator's purpose would be to verify clang's suitability for an 
IDE, at least from the aspect of syntax/semantic colorizing. For example 
it would answer questions like:
-Can I colorize all variable names ? (with exclusive color)
-Can I colorize all type names ?
-Can I associate opening/closing braces for all kinds of blocks 
(namespaces, functions etc.) ?
-Does the AST carry enough information for doing [insert task] ?

Now, assuming that you have a working Annotator lib, the best way to put 
it to use (without messing with some IDE) would be to make a HTMLAnnotator.
HTMLAnnotator would be a client of Annotator and HTML Rewrite API.

What do you think about the above ?

> I don't believe that an IDE would be an ASTConsumer (in the clang 
> driver sense) either, but would rather interact with the clang 
> libraries interactively to regenerate ASTs on-the-fly.

I was thinking that in the specific task of semantic colorizing, you 
would have to utilize Preprocessor+Parser+Sema for a particular source file,
so the Annotator being an ASTConsumer, that handles the declarations 
that the parser gives it, seemed reasonable, do you have something else 
in mind ?


-Argiris