Yes, I don’t think it is foreseen in the protocol. So-called “payloads” go in this direction, but they are limited and deprecated:
https://jupyter-client.readthedocs.io/en/latest/messaging.html#payloads-deprecated
A possibility would be to have the kernel send messages with a custom MIME type (e.g. “text/texmacs-command”) and flush the data of such messages as Scheme back to TeXmacs.
It is technically possible to add widgets to the document, but as @mgubi notes we have to be careful about the right way forward. Examples of currently implemented interaction within the document would be the buttons of a fold and the “Draw image” functionality.
The buttons of a fold are quite minimal, so they don’t disrupt the document in a major way. With image drawing the mouse interaction happens within the document, but the main UI elements are in the toolbar.
This would be a variant of the second option in the list of @mgubi above. If we activate the interactive Jupyter element, the controls could appear in a custom-made toolbar.
I know very superficially Jupyter (I have used it once or twice, and only for interacting with Python), but my feeling is that it is a good temporary solution for having many plugins, and not a permanent solution.
The feeling comes from this: Juypter is a document, which supports interaction with programs.
With Juypter inside TeXmacs there is a document inside a document, supporting interaction with programs.
The idea to make values editable from the focus bar is very nice and natural (I was not thinking about it :)). It is actually something we could implement easily right away. Somehow we could also extend this idea to make a large class of values editable via sliders or similar UI, e.g. the font size for some paragraph, etc… Joris was thinking since some time to have some “inspector” UI to operate on document. In the same way we could operate on values from the Plugin or even on the code itself, e.g. to choose colors, like many CSS editors do.
We don’t really have a Jupyter document inside of TeXmacs with the plugin. You are probably thinking of the Jupyter Notebook. This is separate from the kernels that do the actual computation, but don’t store the document. The TeXmacs plugin is a replacement for the Notebook, it talks with the Jupyter kernels, sending it commands and receiving the results to render.
I wouldn’t have thought about it without your suggestions, either 
An inspector UI would be aweseome! I’m never sure about which variables are set where.
Here’s a screenshot just for fun!
Four times the Lorenz attractor: in Python, Julia, SageMath and Octave 
EDIT: centered now
Can you center better the document? I would like to post it on the twitter account.
Thanks! I posted the landscape picture.
Very nice ! Thanks for sharing.
I still have to see a nice way to do help and documentation which integrates with TeXmacs. I think if we find a nice solution then it would not be difficult to integrate it in our various plugins. Somehow all of them share the same problems in this respect.
Hi @mgubi, I’m also interesting to use Julia in Texmacs. I see that you are working in that and thak’s a lot for that. I would like to know if there is any progress of the plugin that I can install.
You can either use the Jupyter plugin here
or the julia plugin here
there are both working and essentially functional, just maybe looking for some enhancements and maybe bug reports. You are welcome to try them and let us know. Read the README.md for installation. It should be quite easy.
The Jupyter plugin seems not be able to communicate with the server anymore. It would need to look deeper into the problem. The glue code is written in Python, so if you know enough python you could be able to solve it, or at least help to debug. If you are just interested in running Julia, you can just use the Julia plugin. But unfortunately I’m not using either of these programs so I didn’t had time to keep the plugins working. Maybe @darcy or @jeroen have some ideas? Can we fix easily these problems?
I’m planning to improve the Python plugin in Mogan in the near feature.
And making Julia plugin built-in is scheduled within 6 months.
And now, I’m busy integrating LLM services to the commercial version of Mogan and try to sell the software or the tokens.
Just created a HTTP client in Goldfish Scheme for connecting to LLM APIs.
I don’t know exactly what is going on here, it seems like the ZMQ library has changed.
In order to avoid having to maintain the plugin code for such changes, I at one point started to write a minimal plugin that depends on the jupyter-client module instead: https://codeberg.org/woutersj/tm-jupyter-client
I think it should still work, but I haven’t tested it much, so there are probably bugs.
Let me give it a try
