[mcclim-devel] presenting expressions, nested presentations
Hi, Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented? Well, consider the code at the end of this mail; it achieves this, but at a price: we no longer respect *print-level*, *print-length* and friends; we don't honour *pprint-dispatch-table* (which might have EQL "methods" on these objects); and there appears not to be a way of finding out what the user would prefer to be the :single-box attribute of the nested presentations. The *print-level*/*print-length* and friends could be worked on with a little bit more code; the *pprint-dispatch-table* issue, however, is rather more fundamental; if it can be handled at all, it would need to be handled on an implementation-level basis (there's no GET-PPRINT-DISPATCH exposed to the user, only SET-PPRINT-DISPATCH). I presume that the :single-box issue we can deal with ourselves by inventing a special variable. Really, what I would like to know is what the requirements for this presentation method are. What do I have to do to honour the ACCEPTABLY keyword? Is managing *print-level* and *print-length* enough (well, presumably there's more work to be done to support *print-array* and so on)? Should we do this for user-defined structures as well, where we can determine that there is no applicable *pprint-dispatch-table* or PRINT-OBJECT method (fortunately, there can be no user PRINT-OBJECT method on conses or vectors). I suppose the inevitable question is: what did the Lisp Machines do...? Answers welcome! Cheers, Christophe (define-presentation-method present (object (type expression) stream (view textual-view) &key acceptably for-context-type) (declare (ignore for-context-type)) (let ((*print-readably* acceptably)) (typecase object (cons (with-output-as-presentation (stream object type :single-box t) (princ #\( stream) (do ((o object (cdr o))) ((null o)) (present (car o) (presentation-type-of (car o)) :stream stream :view view) (cond ((null (cdr o)) (return)) ((listp (cdr o)) (princ #\Space stream)) (t (princ " . " stream) (present (cdr o) (presentation-type-of (cdr o)) :stream stream :view view) (return)))) (princ #\) stream))) (simple-vector (with-output-as-presentation (stream object type :single-box t) (princ "#(" stream) (do ((i 0 (1+ i))) ((>= i (length object))) (present (svref object i) (presentation-type-of (svref object i)) :stream stream :view view) (when (>= i (1- (length object))) (return)) (princ " " stream)) (princ #\) stream))) (t (prin1 object stream)))))
Christophe Rhodes <csr21@cantab.net> writes:
Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented?
Yes!
we no longer respect *print-level*, *print-length* and friends; we don't honour *pprint-dispatch-table* (which might have EQL "methods" on these objects);
Hmm. This is probably not a good idea in a Listener, as it's supposed to be an enhanced REPL - its Lisp behavior should preferable be indentical to the standard TTY REPL.
and there appears not to be a way of finding out what the user would prefer to be the :single-box attribute of the nested presentations.
Your method draws the box around the innermost presentation (or from the beginning parenthesis to the ending parenthesis). Surely this is the resonable choice? Or do I misunderstand?
What do I have to do to honour the ACCEPTABLY keyword?
If ACCEPTABLY is true, you just have to make sure whatever you print is valid (textually) input to the corresponding accept method. It has nothing to do with what can be understood by READ (though it's probably a very good idea to also make it readable).
Is managing *print-level* and *print-length* enough (well, presumably there's more work to be done to support *print-array* and so on)?
I would consider it more important than pretty-printing, at least, because being able to prevent CLIM from drawing too large expressions at the Listener is probably necessary with the current McCLIM drawing performance, while pretty-printing is more of an aesthetic issue. However, should *print-level* and *print-length* also be respected when some arbitrary application presents expressions? That might be a bit nonintuitive.
suppose the inevitable question is: what did the Lisp Machines do...?
We better find McCLIM a corporate sponsor so we can get one and check it out. :-) -- \ Troels "Athas" /\ Henriksen
On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote:
Hi,
Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented?
Another place this would be nice is in CLIM's DESCRIBE, since it's disappointing to have a tree presented through CLIM's describe, and then be unable to mouse around on its contents...
Alternately, I've been thinking it would be useful to integrate the inspector into the listener, so that you can immediately start clicking your way through returned values. I hadn't considered the interaction with the select gesture (lacking working subform accepting until recently, it wasn't much of an issue). I think this is a cool idea, but requires some decisions be made as to what UI gestures are used. Does anyone else think this is a cool idea? On 11/21/06, Robert P. Goldman <rpgoldman@real-time.com> wrote:
On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote:
Hi,
Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented?
"Andy Hefner" <ahefner@gmail.com> writes:
Alternately, I've been thinking it would be useful to integrate the inspector into the listener, so that you can immediately start clicking your way through returned values.
By expanding parts of the accept result in-place, as if there was a Clouseau embedded in the pane? That would be useful; in fact, that's half of my Clouseau use cases. Also, it would make for great screenshots!
I hadn't considered the interaction with the select gesture (lacking working subform accepting until recently, it wasn't much of an issue). I think this is a cool idea, but requires some decisions be made as to what UI gestures are used.
Why not just use a composite gesture such as M-button1, or perhaps the middle mouse button? Or maybe we could consider inspection a form of a description, and use the :describe gesture. I think I prefer M-button1.
Does anyone else think this is a cool idea?
Yes, it's a really great idea! The Listener is an important tool, so it should have as many of these neat features as possible. -- \ Troels "Athas" /\ Henriksen
I was imagining just using this on return values and other compatibly presented objects. I suppose the idea applies to accept-results too, but I'm having trouble imagining the purpose (where did the accept-result come from, if not somewhere else in the window where you could inspect in a less confusing fashion?). If you've got some wild ideas for ways to apply Drei, I'd like to hear them. On 11/21/06, Troels Henriksen <athas@sigkill.dk> wrote:
"Andy Hefner" <ahefner@gmail.com> writes:
Alternately, I've been thinking it would be useful to integrate the inspector into the listener, so that you can immediately start clicking your way through returned values.
By expanding parts of the accept result in-place, as if there was a Clouseau embedded in the pane? That would be useful; in fact, that's half of my Clouseau use cases. Also, it would make for great screenshots!
"Andy Hefner" <ahefner@gmail.com> writes:
I was imagining just using this on return values and other compatibly presented objects. I suppose the idea applies to accept-results too,
Sorry, I guess I hadn't properly swapped out what I was working on before I replied. I meant "return values", not "accept results".
If you've got some wild ideas for ways to apply Drei, I'd like to hear them.
In-buffer inspections of literal buffer objects is a hack that begs to be written, but I'm quite sure this is not in any way useful. Apart from the obvious possibility of inserting objects from the inspector tree into the new input line, I'm not sure how an editor could be (or should be) meaningfully integrated with an inspector. -- \ Troels "Athas" /\ Henriksen
On Tuesday 21 November 2006 05:50 pm, Andy Hefner wrote:
Alternately, I've been thinking it would be useful to integrate the inspector into the listener, so that you can immediately start clicking your way through returned values. I hadn't considered the interaction with the select gesture (lacking working subform accepting until recently, it wasn't much of an issue). I think this is a cool idea, but requires some decisions be made as to what UI gestures are used.
Does anyone else think this is a cool idea?
I do, but note that this is not quite what I was hoping for --- I was hoping for this to be available in the built-in McCLIM describe, which is available to all McCLIM applications, not just the Listener. I like to make an application and have describe available for help with debugging. Perhaps I should just figure out how to make Clouseau available...
On 11/21/06, Robert P. Goldman <rpgoldman@real-time.com> wrote:
On Tuesday 21 November 2006 04:14 am, Christophe Rhodes wrote:
Hi,
Wouldn't it be cool if, when we presented list data as an expression, the contents were individually presented?
_______________________________________________ mcclim-devel mailing list mcclim-devel@common-lisp.net http://common-lisp.net/cgi-bin/mailman/listinfo/mcclim-devel
participants (4)
-
Andy Hefner -
Christophe Rhodes -
Robert P. Goldman -
Troels Henriksen