[mcclim-devel] presentation example from docs

[Cyrus Harmon]

Ok, so while this fixes things, it has the unfortunate effect of  
putting the text "The third month" in quotes in the prompt box. Not a  
showstopper, obviously, but not as nice as one would like for a piece  
of expository code.

Also, the arguments prompting thing in general just feels really  
hokey. Lots of little bugs. I imagine they could be cleaned up, but  
this is one of thing that scared me away from mcclim initially and I  
imagine others might feel similarly. Not to be too negative, but I  
want to 1) point it out and 2) learn enough so that I might be able  
to do something about it.

Thanks,

Cyrus

On Feb 10, 2007, at 1:12 PM, Troels Henriksen wrote:

> Cyrus Harmon <ch-mcclim at bobobeach.com> writes:
>
>> Granted this is a minor gripe but when I run the presentation example
>> given in the manual, the manual says I should see that output "the 15
>> or The third month" when I click on the shown objects. In fact I get
>> "the 15 of THE". Is the manual in error or is something wrong here?
>
> This is a bug that Goatee is able to handle, but Drei is not. It
> happens due to the default present/accept methods for presentation
> types (which is quite a kludge in itself) that just invokes print/read
> on the objects and try to wing it that way. This works very poorly,
> since the presentation of a string will then be "string", but that
> can't be read in by the corresponding default accept method, because
> it uses `read-token' to get the string, and that removes the quotes
> (so it'll be interpreted as a symbol by the reader, but that won't
> work well if the string has whitespace in it, this is why you only see
> the first word, and in uppercase). Goatee is somehow able to detect
> that the result of presenting the object to a string is not acceptable
> back in, and thus puts in an "accept extent" (roughly, a reference to
> the actual object that is returned instead of attempting to parse the
> string). I don't quite know why Goatee detects it, it's probably an
> accident. :-)
>
> In any case, the central problem is accepting textual input of
> presentation types that do not have accept methods. Bad, bad, bad.
>
> -- 
> \  Troels
> /\ Henriksen