I believe that I have found the reason why argument handling was not working for me. The bug was that when I selected an object as an argument, it was drawn in the argument space as a string, and then reparsed.
The above works fine for arguments that can nicely be turned into strings and then parsed back (Christophe, your example of CLOS class names in the listener falls into this class of argument), but it doesn't work well with things that cannot be parsed from strings.
The error was a flipped if statement, way down in the drei input editor, in present-acceptably-to-string. This if statement stripped off the object information from an argument when it was *successfully* presented to a string, rather than when it was *unsuccessfully* presented.
I attach a patch file. Unless someone finds a mistake, I will commit it tomorrow before the weekend.
Best, Robert
Robert Goldman rpgoldman@real-time.com writes:
I attach a patch file. Unless someone finds a mistake, I will commit it tomorrow before the weekend.
Actually, the code works fine (though perhaps a bit illogical, I just adapted it from Goatee) - `present-acceptably-to-string' is only supposed to return a non-NIL object if the textual output is NOT acceptable. If we can represent the object as a string, we have no need for the object information. See `presentation-replace-input' just below the definition of `present-acceptably-to-string'.
As I hope minion told you on #lisp, the problem is that Drei has to invoke magic in order to figure out whether the textual output of a presentation method can be accepted back in by an accept method (and if it can't, insert a literal object instead of text). CLIM has no formal way for a presentation method to say "no, I cannot fulfill your request for output with :acceptably t", and hence Drei (and Goatee) tries to wing it by assuming/hoping that presentation methods will signal an error if they are provided with a true value for the :acceptably keyword parameter, yet cannot actually perform textually acceptably output. This is the case for the default fall-through presentation method, but it's very likely to malfunction for user-defined presentation methods.