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.