> Your suggestion of Documentation classes comes but one month after I
> suggested the very same.

Oh funny... maybe I read it quickly and got the "inspiration" from that :).

The thing is I always find there are too much click to see a class
comment (one more in OB)... I'd like comments to spring to my face :)
and stay there as long as I use a given class...


>
> I liked the idea but had several questions as to how to make the idea
> work well. I had no replies to these questions, but there was some
> debate as to the concept. (If you look in older versions of Sake, in
> http://www.squeaksource.com/Sake you will find an implementation lurking
> in there some where as SakeDocumentation)
>
> Question 1. As far as my experiments show overriding #compilerClass to
> point to a null compiler works. However it only works for instance side
> methods. I wanted to know where one can select the #compilerClass for
> class side methods.
>
> Question 2. With this scheme no one tells "Shout", so it continues to
> try and auto format the text thinking it is a normal method. Is there a
> way to make shout aware on a per-class basis what language it is
> highlighting.
>
> My personal conclusion was to experiment with the idea to see how useful
> it was within a particular domain... my experiment simply causes the
> compiler/parser to ignore code after a line consisting of """""".
>
> My second idea is to use the symbol ˚ in methods that are documentation,
> such that #task˚ documents #task.
>
I'm quite fine with method comment. You did this changes to be able to
really put anything in the comments, wich is not possible right now
("" inside a method comment is problematic)

What I'd like is a quicker ways to access them, like a tooltip. A
method-category comment could held all method comment it contains...

Thanks for the precisions Keith :)