Add more REPL customisation features for JupyterLite 0.6.0 (DO NOT MERGE)

[agriyakhetarpal]

Description

This PR closes #275; it adds the new REPL configuration options for the Replite directive from jupyterlite/jupyterlite#1573 and associated documentation for these options. Like the previous addition via #245, these options are also configured via URL parameters and can be configured either globally or via a per-directive basis. Many of these options are in camelCase, and are converted to snake_case accordingly.

[agriyakhetarpal]

While this PR is titled as such because JupyterLite 0.6.0 isn't ready yet, the PR is ready for review as it can help catch upstream issues before the stable release, as directed in #275 (comment).

[agriyakhetarpal]

So, I think there is a bug with the REPL when it is accessed in fullscreen mode and with the code execution disabled, and when the inserted code snippet is longer than a one-liner. For example, the following REPL:

https://jupyterlite-sphinx--290.org.readthedocs.build/en/290/lite/repl/index.html?kernel=xeus-python&execute=0&clearCellsOnExecute=0&clearCodeContentOnExecute=0&hideCodeInput=0&showBanner=1&promptCellPosition=bottom&code=import%20matplotlib.pyplot%20as%20plt%0Aimport%20numpy%20as%20np%0A%0Ax%20%3D%20np.linspace(0,%202%20*%20np.pi,%20200)%0Ay%20%3D%20np.sin(x)%0A%0Afig,%20ax%20%3D%20plt.subplots()%0Aax.plot(x,%20y)%0Aplt.show()

The code execution works well here as expected, but the code snippet seeps into the bottom of the page and then out of it, as the code prompt does not fit within the screen.

Here is a video recording if this helps:

Screen.Recording.2025-05-07.at.18.55.24.mov

---

However, this isn't the case with the same code snippet on the stable documentation:

https://jupyterlite-sphinx.readthedocs.io/en/stable/lite/repl/index.html?kernel=xeus-python&execute=0&code=import%20matplotlib.pyplot%20as%20plt%0Aimport%20numpy%20as%20np%0A%0Ax%20%3D%20np.linspace(0,%202%20*%20np.pi,%20200)%0Ay%20%3D%20np.sin(x)%0A%0Afig,%20ax%20%3D%20plt.subplots()%0Aax.plot(x,%20y)%0Aplt.show()

---

I investigated the CSS, and what I understand is the elements lm-Widget lm-Panel jp-CodeConsole-content lm-SplitPanel-child and lm-Widget lm-Panel jp-CodeConsole-input lm-SplitPanel-child are now possible to be moved with JupyterLite 0.6.0a9 (as this is what has been changed, of course), but in the stable version we just have lm-Widget lm-Panel jp-CodeConsole-input, and thus that will always stay within the screen regardless of the length of the code snippet.

The bug occurs on all prompt positions, but is primarily noticeable when the prompt position would be set to bottom/top, as a long code snippet won't overflow if the prompt is positioned at the left/right unless the code snippet is super long (i.e., even for the left/right positions).

The bug's effect is amplified when the REPL is in an iframe, where the code snippet may be very long and the REPL might be only on a limited portion of a page, which makes things a little awkward.

I think the ideal solution would be for the code prompt to expand to the length of the code snippet every time, or to never go out of the screen. I guess we need a min-width: fit-content or similar style for these?

Please let me know if you'd like me to open a new upstream issue for this, @jtpio, thanks! Happy to move it around to https://github.com/jupyterlite/jupyterlite if you want and I can perhaps try to fix this if it's not too difficult 😅

[jtpio]

So, I think there is a bug with the REPL when it is accessed in fullscreen mode and with the code execution disabled, and when the inserted code snippet is longer than a one-liner. For example, the following REPL:

Right this is likely a side-effect of the switch to using a SplitPanel in the JupyterLab code consoles, which allows for resizing.

JupyterLite reuses the code console from JupyterLab almost as-is, and these new changes were added in JupyterLab 4.4: https://jupyterlab.readthedocs.io/en/latest/getting_started/changelog.html#code-console-improvements

So maybe we should look into a fix in JupyterLab so the SplitPanel adjusts its size based on the code in the input cell? Or have that logic in JupyterLite directly? But then is the user adds more line to the input cell manually, it's probably fine if the SplitPanel does not adjust its size?

[agriyakhetarpal]

Thanks for your quick response!

JupyterLite reuses the code console from JupyterLab almost as-is, and these new changes were added in JupyterLab 4.4: jupyterlab.readthedocs.io/en/latest/getting_started/changelog.html#code-console-improvements

So maybe we should look into a fix in JupyterLab so the SplitPanel adjusts its size based on the code in the input cell? Or have that logic in JupyterLite directly?

Ah, I see. I think both options would be fine here. Given that JupyterLite is reusing most of the code, someone is bound to run into this in JupyterLab as well, so it makes sense to fix there. We could also override this on the JupyterLite side to fix it temporarily, as you've mentioned that the first beta is coming in jupyterlite/jupyterlite#1554 (as I'm not sure what the usual release schedule is and if there are any timelines to keep in mind)

But then is the user adds more line to the input cell manually, it's probably fine if the SplitPanel does not adjust its size?

Right, I imagine that if someone adds more code, the scrollbar should return – the SplitPanel should only be rightly sized at the beginning, at the time of loading the page.

[jtpio]

We could also override this on the JupyterLite side to fix it temporarily

The option for populating the code cell with code is provided by the JupyterLite plugin in https://github.com/jupyterlite/jupyterlite/blob/main/packages/repl-extension/src/index.ts. So maybe we could first try to look into it there?

the first beta is coming in jupyterlite/jupyterlite#1554 (as I'm not sure what the usual release schedule is and if there are any timelines to keep in mind)

There isn't a strict timeline, but it would be great to move forward with the 0.6.0 final release this month, once the remaining PRs that add new features have been merged. And changes like this one can be done at any time if they are considered as bug fixes.

[agriyakhetarpal]

Okay, I've been doing this for a decent amount of time (more than a couple of hours) and haven't gotten far. I think one problem that makes things tricky is also that the code added by the &code= URL parameter is apparently added after the page and the initial styles are loaded (if I am understanding this correctly). So, we need to anticipate and observe when the code will be added into the code prompt and then act on it, and at this point I think it's too late for us to do so. I tried both a setTimeout() approach and a MutationObserver one, but neither is sufficient.

I'll set this aside for now, as this should not be a big blocker against merging!