The more fundamental question is why you use a special protocol. Why can't you use the existing infrastructure and send the string with the id as a list like we do in the inspector?
Helmut.
Ah, you are the one I should be chicken of, not Luke :) (see my checkin comments)
I wish I could figure out a better way, but I haven't yet. Maybe you all could help me.
The reason that I think I can't is because rather than the in the case of the repl result, or the backtrace, we are expecting the thing being passed back to have some specific structure, at a specific time. On the other hand presentations are intermingled with arbitrary output, only a portion of which I have control over.
So take the case of hooking into print-unreadable-object. You don't get to choose when it is called. So when it is called and you want to make something sensitive you need to signal that somehow.
The issue here is synchronization. Let's suppose that we were writing to a stream straight to lisp output. Theoretically when we want to print something sensitive we could flush the stream, force the output event to be sent to emacs, then send a different kind of event for the sensitive object, and then resume output. But I don't know if that's possible when using the dedicated stream, and I didn't spend time looking at the non-dedicated stream case to see if it was possible there, since I didn't think it was an option to avoid use of the dedicated stream. (there might be performance issues as well...)
But there are other problems because during pprint you often are not writing directly to the final destination stream. As I understand it there is buffering in order to decide layout, so you don't really know, when you are about to start printing a sensitive object, how much text is buffered up. Thus you would have to be able to leave some synchronization mark, I think, which this strategy amounts to.
One could imagine intervening on the lisp side - catching the markers there at the stream-tyo level, stripping them, and then sending a separate message to slime about where the boundaries are. Here you seem to have a similar opportunity to handle the synchronization. But I don't think this makes it any cleaner, it just shifts the messiness to the lisp side.
I think the clean alternative is to essentially take over printing output in a more pervasive way and have it be aware of the fact that output is presentation based and not text based. But I also think that it is very intrusive and time consuming to do it. It is, as I understand it, what is done on lispms, and in Mcclim. It is possible that the Mcclim listener code might be adapted - I haven't looked into this. There are issues with the current implementation, like what to do about nested sensitive objects (a list presentation that contains a number of element presentations), that are better addressed in a broader framework.
So the bottom line is that I just can't figure out a better way to do it. And I'd rather do it messy than not do it. But I'd rather do it clean than messy, so maybe you and others can help by suggesting a nicer way of implementing this.
This doesn't look like the right place to do it. slime-open-stream-to-lisp is only called if the dedicated output stream is used. If the dedicated stream is disabled the markers will not be scanned. You could do the scanning in slime-output-string.
Yes, I thought of this. The issue that needs to be handled is that, as I understand it, you don't know where your string is going to be broken when calling slime output. So you have to manage remembering that you are in the middle of a potential marker regular expression and holding on to previous output until a subsequent call resolves that you have or have not seen a marker. This is what the bridge does. It is a non trivial amount of work so I decided to use their code for a first pass, so we could see if the idea even felt ok. But I didn't realize about the non-dedicated stream case. I'm not averse to making this work, though I think I'd wait to make sure some other showstopper doesn't show up so I don't waste my time.
Looking forward to your future thoughts and comments,
-Alan