[slime-devel] For presentation fans

[Alan Ruttenberg]

> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: text/enriched
Size: 4313 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/slime-devel/attachments/20050520/3d6e23df/attachment.bin>