I've some questions about the presentation stuff:
1. 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.
2. 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?
3. 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.
Helmut Eller heller@common-lisp.net writes:
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.
The bridge code has never worked cleanly for me (sometimes I see partial escape sequences in the output). Also, I think that the method of signalling presentations by printing escape sequences is inherently broken because it messes up the character position, which disturbs the pretty printer layout. Hence I agree with your suggestion to remove the bridge code.
I would suggest to automatically turn off the dedicated output stream when presentations are in use.
Alan's point about the speed of the bridge-less presentation code is valid, of course. I think we should try to speed up this code; I do not have time to work on this, though.
- 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?
We definitely need text properties for associating presentation _data_ with the text, because overlays do not get copied. For implementing the visual mark-up, I am currently using text properties (which do get copied) and overlays (which allow highlighting of nested presentations). (Try (describe 'standard-object) in CMUCL and mouse over the #<Wrapper...> object.) Again the problem is that overlays do not get copied with the text. I have been thinking about using overlays only for the visual markup; then the after-change function will need to be extended to create overlays for marking up presentations and to delete them when the presentations become invalid. I don't know whether this technique will work better for Emacs 20, but it will be worth a try.
- 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.
I would think it is not needed any more.
On Sep 4, 2005, at 6:17 AM, Matthias Koeppe wrote:
- 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.
I would think it is not needed any more.
Is that true even for the bridge code version?
Thanks, Alan
On Sep 4, 2005, at 6:17 AM, Matthias Koeppe wrote:
The bridge code has never worked cleanly for me (sometimes I see partial escape sequences in the output).
This is what I'm looking at trying to fix. I see the same thing. I used to see spurious "NIL" printed in the middle of long output to the repl - I'm wondering if whatever was causing that is related.
Also, I think that the method of signalling presentations by printing escape sequences is inherently broken because it messes up the character position, which disturbs the pretty printer layout.
Just wanted to point out that pretty printing isn't the only use case. It isn't the primary use in my work. Also, again, I haven't looked closely, but can the annotation approach you used solve this problem?
-Alan
Alan Ruttenberg alanr-l@mumble.net writes:
Just wanted to point out that pretty printing isn't the only use case. It isn't the primary use in my work.
I agree, but pretty printing is often enabled by default, and it is not nice if the layout (for instance that of DESCRIBE) is messed up.
Also, again, I haven't looked closely, but can the annotation approach you used solve this problem?
I use annotations to make presentations work within pretty printing streams (of CMUCL, SBCL, and Allegro CL). Unfortunately, annotations do not help outside of pretty printing streams: Consider (LET ((*PRINT-PRETTY* T)) (FORMAT STREAM "~&~A ~A~%" OBJECT1 OBJECT2)). Here two pp streams are created in sequence. After OBJECT1 has been printed, the pretty printing stream for OBJECT2 bases its layout decisions on the character position of STREAM. Presentation escape sequences used for printing OBJECT1 will therefore influence the layout of OBJECT2. Unfortunately, at least in CMUCL and SBCL when STREAM is a (built-in) Lisp stream, there is no way to influence the character position, to correct it for the escape sequences.
-
Alan Ruttenberg -
Helmut Eller -
Matthias Koeppe