My opinions:
On Sep 2, 2005, at 6:46 PM, Helmut Eller wrote:
I've some questions about the presentation stuff:
- now that we have explicit messages for presentations in the protocol, can we remove the bridge thing? Yes, I know that presentations will then not work with the dedicated output stream, but that's a efficiency hack and layerying the bridge kludge on top of the efficiency hack is so ugly, it makes me cry. I'll remove it, if there are no objections.
Please don't. I tried not using the bridge version today and it was *much* slower. Annoyingly so. Unless you have some other idea about how to make the thing run faster. For that matter I've been poking around trying to understand how to make the bridge version run even faster.
Maybe there is a way to structure the code differently so that it isn't so, um, stimulating. It could very well be time to refactor.
BTW, Note that there is some bug in the bridge stuff that I keep running into. I am trying to debug it currently.
- is there another way to handle presentations than with after-change-functions? Our after-change-functions are totally broken in Emacs20. Could we use overlays instead of text properties for presentations?
Don't know this stuff well enough to know. My first versions used a different mechanism that wasn't as elegant, but might have been more backwards compatible.
- is *can-print-presentation* still needed? It seems to me that slime-stream-p serves about the same purpose, but it is much cleaner. It's also ugly the we need to bind *can-print-presentation* in a lot of unrelated/random places.
The intent of *can-print-presentations* was to avoid the use of presentations in places that couldn't handle them like the inspector and sldb. I had thought that at some future time I would think about whether they had any use there and possibly make them work if so. I haven't caught up with all of Matthias' changes yet, so I'm not sure if it is necessary any more.
---
FYI, I have a few features that I've been thinking of adding.
1) Style - Bold, color, tooltips. 2) Updateable presentations. I have some cases where I want to leave a marker for something that will take some time to compute and later update the presentation with the computed result. 3) Separate stream/process to handle presentation events so that they can be active even when the repl is busy.
-Alan
Alan Ruttenberg alanr-l@mumble.net writes:
FYI, I have a few features that I've been thinking of adding.
- Updateable presentations. I have some cases where I want to leave
a marker for something that will take some time to compute and later update the presentation with the computed result.
I think it would be great if one could get REPL-like behavior in arbitrary buffers, for instance the *slime-scratch* buffer. So I could start (computation-1) and (computation-2) in different places of the same buffer, watching their output and waiting for their results. There could be a placeholder (your updateable presentation) that shows that the computation is still running; output would be inserted in front of the placeholder.
- Separate stream/process to handle presentation events so that they
can be active even when the repl is busy.
I think this works already.
-
Alan Ruttenberg -
Matthias Koeppe