Andrei's Google Talk

[Walter Bright]

Steven Schveighoffer wrote:
> I just did (fixed a lot of stuff in the array page).

Thank you.

> A couple comments:
> 1. There is no guideline for updating the spec (at least that I could 
> find).  I deduced $(V1) and $(V2) and figured out what $(LNAME2) is, but 
> lack of guidelines may be partially to blame for why few people edit it.
> 2. It seems like the documentation is HTML written as ddoc.  I see $(P) 
> tags, $(LI) tags, etc.   Can't we just write it as HTML?

Nooooo, I tried to get away from that! HTML is a horrible format. Besides, I've 
also had thoughts of being able to use the macros to generate things like Latex 
output or man page output from the same source text.


> I think many 
> would feel much more comfortable that way.  It's also more supported by 
> editors.  I forgot a closing parentheses on one tag, and it screwed up 
> the entire page.  I had to find it by hand, whereas an HTML editor could 
> red-flag a tag without a closing tag, or you could run it through an XML 
> verifier (if it's xhtml).

I often make that mistake. But the editor I use (microemacs) has a fabulous 
feature, F3, which finds the matching ( { [ < > ] } ) #ifdef/#elif/#else/#endif 
when the cursor is placed on one of those. It makes it utterly trivial to find 
the mismatch.

BTW, back when the doc was in HTML, it was absolutely rife with mismatched HTML 
open and close tags. The fact that browsers would render it anyway I did not 
regard as a feature. The Ddoc macro format helps enormously in generating 
*correct* HTML. I've now got the entire D website using Ddoc, and the macros 
have enabled me to establish a common, and customizable, look and feel across 
the entire site just by adjusting the macro definitions.

The other feature of the macro method is, obviously, that they can be customized 
to generate all sorts of things. I believe that candydoc relies on that.