-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Adding metadata/styling from repr output #14
Comments
i wanted to wait for notebook itself to implement such functionality, but actually we could do this ourselves. anyway: can you find the notebook issue about this? there has to be one… |
At least my search-foo didn't find one in jupyter_client and now notebook and the old ipython one. But for me, the pro/con list makes it pretty clear that this is not a thing which should happen in the notebook backend/frontend but on the kernel... Just imagine a plot library adding their own xxx kb css and js files to each call (maybe even 2x because html and markdown output?) and then having that in the ipynb file :-( In knitr, the stuff never reaches the final output file, so it's similar to an in-kernel-solution. |
Tricky, because what if the output which has the styling is cleared later? |
Oups, that the reverse "restart the kernel" problem... so reruns of all cells (or just the one which got the styling) do not work... So it seems we really need something in the notebook and do it there? |
@jdfreder put together a proposal to help with this and it's generally unsolved. |
[edit]
Currently, without a change in the frontend, the best we can do is simple send the complete metadata to the frontend in the normal display data: If we manage the styling, we send the styling only once on the first exec of such code. But then the frontend (=Notebook) could reevaluate the cell which currently has the styling and we would no notice this and no send styling, and the notebook would end up without styling information.
See also jupyter/notebook#116 and jupyter/roadmap#9
[/]
It would be nice to be able to specify that something only needs to be displayed once, e.g. the styling for a table or an interactive plot.
The repr side probably only needs to document the way this should happen, the actually implementation needs to be in the display package.
From the old issue comment by @flying-sheep:
yeah, the point is that there needn’t be a new interface: we can simply add attributes to the
character()
/raw()
returned, which avoids changing signatures.an example where i loop a bunch of things, create their HTML reprs and only do setup once:
PS: for the implementation, we should have a list of seen setups, keyed by format and class. this way there will be less potential for name collisions. or we just us the passed code itself as key.
The text was updated successfully, but these errors were encountered: