WIP: display_with_id

[pfitzseb]

ToDo:

• figure out better API for consumers (maybe MIME based)
• adjust indices in map when deleting plots

[jkrumbiegel]

Depending on the content it could be important to retain zoom setting across updates, I can imagine users would try to zoom into a changing plot once in a while, which would then be jarring if it was reset.

[pfitzseb]

Yeah, that's annoying (as-is for users, implementation wise for me :P):

[jkrumbiegel]

implementation wise for me :P

The most obvious behavior for users is usually the most annoying to implement..

[thompsonmj]

Regarding an minimum viable version of this feature, 'zoom retention' could be taken care of using xlim and ylim in the plot command and is a bit of a bell/whistle imo.

I'll also echo what @davidanthoff said in Slack ...

I think it would be cool if we either had a UI toggle "Replace last plot with next plot" or something like that, or maybe a flag in the vscodedisplay function or something like that. But I think the UI toggle would be best.

Call this toggle "Iterative plot mode," and it could live in the plot pane's "More Actions..." ellipsis. Have a hover info tag that could explain what it means with something like:

In iterative plot mode, each new plot deletes the previous plot. This is useful in cases where you would like to visualize the real-time evolution of a process over many iterations. We recommend using the sleep() or mod() functions to avoid lag between the visualization and program states.

[jkrumbiegel]

Instead of MIME type, would it make sense to do this via a special IOContext flag? Like passing vscodedisplayid => 123 or so. Then one wouldn't need to depend on the VSCode package to use the function and it would function like normal display otherwise.

[jkrumbiegel]

Although of course MIME wouldn't need a dependency either now that I think about it. Maybe that's better then as it's more explicit. And maybe it's better if it errors instead of silently doing nothing, as otherwise one would be pushing many plots that are meant to be thrown away but then accumulate in memory.

[jkrumbiegel]

Another idea, how about MIME type plus NamedTuple such that there's an easy way to pass the ID. So show(MIME"vscodeplotpanewithid"(), (; id = 1, object = xyz) where xyz is whatever you really want to show.

Or is there a better way to pass the id information?

[pfitzseb]

[jkrumbiegel]

Interesting, is it not "weird" to make a MIME type per id? Or are custom MIME types like that fair game

[pfitzseb]

It is kinda weird, yes. Note that the user doesn't actually need to care about that for anything but the display call.

[jkrumbiegel]

I would like to try and advance this, I assume you haven't moved it forward because you weren't satisfied with the MIME type design, yet? To me it still seems clearer to do this via IOContexts, or did you have a specific reason why you wanted to go with the MIME route?