1Re: more on mouse to command presentation0

[RWK@FUJI.ILA.Dialnet.Symbolics.COM (Robert W. Kerns)]

    Date: Wed, 11 Jul 90 23:08 EDT
    From: miller@sol.cs.rochester.edu (Brad Miller)

1    Caveat: I'm sure others have written more presentation code, but here's some
    help anyway.

    You need to define a type using define-presentation-type writing a :printer
    and a :parser for it. 
0There's already a presentation type SYS:FORM defined.  And it's
perfectly allowable to output something in a different manner
than how its :PRINTER is defined, by using DW:WITH-OUTPUT-AS-PRESENTATION
as he is doing here.

1			  The printer presents the object as you like, the
    parser must be able to read the object (or objects you'd like it to match)
    and convert them to the correct output type. You can then use presentation
    translators to make your new type acceptable when the listener is looking
    for a form to input.

    Here's a quick and dirty example.

    e.g. 

    (define-presentation-type pretty-form1 ()
	    :parser ((stream)
		     (accept 'sys:form :stream stream))
0You have a bug right here.  Parsers which call accept should pass along
the other parser arguments, especially DEFAULT and ORIGINAL-TYPE.  I'm
pretty sure this is covered in the documentation of how to write a
parser.

1	    :printer ((object stream)
		      (format stream "~A" (string-downcase (string object)))))

    (present 'TEST-ATOM 'pretty-form1)

    (accept 'pretty-form1)

    this shows we can mouse on the object. Now all you have to do is something
    like

    (define-presentation-translator eval-me (pretty-form1 sys:form)
	    (form1)
	    (eval form1))

0<Screams of pain!>  No, this is awful!!!

You're not up to your usual standards today, Brad.  You want to
take your speedy mouse back to the days of Genera 7.0, I guess.
At least you provide a good example to make a needed point...

Kerns' Rule #1:  Never, Ever, do anything expensive in the body of
translators.  If it's absolutely unavoidable, write an explicit,
inexpensive :TESTER and :DOCUMENTATION.  (EVAL can take an
arbitrary length of time, and the body of this will get run as
:TESTER while deciding what to highlight.  This is because the
body is allowed to indicate non-applicability by just returning
NIL.  (Which is a bug in the design, but is fact)).

Not to mention blowing out in translators is not a good idea!

(present 'fred 'pretty-form1)

(wave the mouse over it, and BLAM!, FRED isn't bound).

Also not to mention that anything looking for a SYS:FORM is going
to do *ANOTHER* evaluation after it gets it.

(setq fred 'kerblewie)

Now wave the mouse over it, and it says KERBLEWIE in the
documentation line.  Click left on it, and BLAM!, KERBLEWIE
isn't defined.  But at least this happens in the code that
called ACCEPT, not deep in the bowels of the presentation
system.  This also clearly indicates the double evaluation
going on here.

Also, if the form evalues to NIL, the translator won't apply; to
avoid this you should return SYS:FORM as the second value.  I
guess if you really wanted the mouse documentation to show the
result of the EVAL, you could have written (VALUES `,(EVAL FORM1)
'SYS:FORM), but that still has all the other problems.

1    (setq mumble 213)
    (present 'mumble 'pretty-form1)

    if you notice, from the listener, mouse-l of the presentation mumble is
    documented as 213 - the result of the eval.

0The only reason you got away with this is that 213 self-evaluates
to 213.

1    ----
     Brad Miller		U. Rochester Comp Sci Dept.
     miller@cs.rochester.edu {...allegra!rochester!miller}