Skip to content

Conversation

@pfitzseb
Copy link
Member

@pfitzseb pfitzseb commented Jun 29, 2022

Peek 2022-06-29 16-21

ToDo:

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

@pfitzseb pfitzseb changed the title WIP: display_with_id initial WIP: display_with_id Jun 29, 2022
@jkrumbiegel
Copy link
Contributor

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
Copy link
Member Author

Yeah, that's annoying (as-is for users, implementation wise for me :P):
Peek 2022-06-29 16-53

@pfitzseb pfitzseb closed this Jun 29, 2022
@pfitzseb pfitzseb reopened this Jun 29, 2022
@pfitzseb pfitzseb closed this Jun 29, 2022
@pfitzseb pfitzseb reopened this Jun 29, 2022
@jkrumbiegel
Copy link
Contributor

implementation wise for me :P

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

@thompsonmj
Copy link

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Contributor

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
Copy link
Member Author

pfitzseb commented Aug 1, 2022

Peek 2022-08-01 13-45

@jkrumbiegel
Copy link
Contributor

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

@pfitzseb
Copy link
Member Author

pfitzseb commented Aug 1, 2022

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

@jkrumbiegel
Copy link
Contributor

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?

@pfitzseb pfitzseb changed the title WIP: display_with_id feat: plot replacement, custom panes, observable support Jul 25, 2025
@pfitzseb pfitzseb marked this pull request as ready for review July 25, 2025 18:00
@oschulz
Copy link

oschulz commented Sep 12, 2025

Bump?

@pfitzseb pfitzseb merged commit 3ef0d97 into main Nov 18, 2025
20 of 21 checks passed
@oschulz
Copy link

oschulz commented Nov 19, 2025

Thanks so much for this!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

5 participants