Hi all,
It should be interesting to take a look at the “new”, promising ant efficient programming language Julia. A Julia plugin’ (and more…) for TeXmacs should be nice.
Unfortunately I don’t have the skills to realise it.
Please take a look at the following link (“How We Wrote a Textbook using Julia”).
https://www.youtube.com/watch?v=ofWy5kaZU3g
Julia programming language
3 Likes
First of all, we should support Julia syntax highlight.
3 Likes
I would really appreciate this. Both the highlighting and the plugin. The former particularly.
2 Likes
I’m trying to write one, mostly to learn about Julia. Also it is not clear to me what we should do. Glad to see it works. We need to discuss to organise our efforts in supporting these languages. What is your impression about Jupyter?
The Jupyter plugin is not very stable yet, but I think that with a bit of effort it could made into a high quality plugin. The amount of languages we would gain is really impressive:
It’s true that not all of these are of the same high quality, but the same could be said about some of the TeXmacs plugins. If we decide to focus more on Jupyter, the effort that is spent maintaining some of our plugins could potentially be directed to improving Jupyter plugins, if needed.
Yes, I agree. Indeed this was my intention with starting it. It would be good to keep a list of the things still to do. One general thing I do not like about the current plugin is that it depends on Python, while generally we should be able to use scheme (or C++) to write it, but this is a minor point. At this point is more important to improve it and make it a reliable replacement to notebooks.
But there is another point to consider: if we rely exclusively on Jupyter then we cannot produce anything which goes out of the capabilities of the Jupyter notebooks. I have in mind here the kind of interactive documents Joris showed us for Matemagix or Pluto where one organise the computations not in cells but in a DAG of reactive values which are updated as needed. This is what interested me in having an independent interface to Julia which does not need (necessarily) to conform to Jupyter protocol. It is still not clear to me if one can produce this kind of interaction within the protocol limits, nor if standard kernels support it.
1 Like
Also note that many of the jupyter kernels above are implemented via https://github.com/Calysto/metakernel so we are just adding layers over layers of scaffolding… somehow this hurts my sensibility 
Overall do not take these as fundamental negative points. I believe we need to polish the tm_jupyter plugin and make it one of the basic plugins in TeXmacs. It seems to me the only sensible choice to do with our limited forces.
Oh no, I agree it’s better to consider all possible downsides before we commit our efforts to something! As you say, they are limited, so we need to think carefully
I’m not familiar with all the details yet, but it seems that dynamic behaviour is possible in Jupyter via update_display_data messages:
https://jupyter-client.readthedocs.io/en/latest/messaging.html#update-display-data
If a kernel implements those, we can assign a “locus” to the displays, like Joris does, and update them if an update message appears.
1 Like
1 Like
One thing that does annoy me about Jupyter is that kernels don’t seem to distinguish help content from execution results and display data. There is a “metadata” field that could be used to tag messages as help or output, but it doesn’t seem to be used. This would have been nice to create a help window separate from the main document.
I always thought that Texmacs was really the forerunner in the area of interactive computational document. A good support of Jupyter kernels should attract A LOT of people.
But what led me to use also Jupyter Notebook was the possibility of using widgets and being able to relatively easily define small applications or utilities based on the principle of dashboards like Voila for example.
https://ipywidgets.readthedocs.io/en/latest/examples/Widget%20List.html
Can Texmacs tend towards this kind of use of widgets or does its architecture not allow it, for the moment at least ?
1 Like
I’m not sure what Joris thinks about this. Certainly the possibility to interact with data in a document is important for scientific/technical research (however it could be maybe overrated). There are two possibibilities as far as I can see
- we can add widgets to documents. Technically is possible but I do not like this very much, they would stand out from the structure of the document and should not print on the paper, etc…
- We can add UI elements to control values in the documents but which do not show up permanently, e.g. they appear only when you hover over the value. This is more coherent with the “vision” of having a document, the UI should not be permanently “impressed” in the document since it does not have a meaning in some situations (e.g. when printing).
- We can allow dialog windows to control certain fields. This solutions would not touch the document structure.
- We find an alternative way to explore the computational space of a document. (which?)
1 Like
TeXmacs allows plugins to inject arbitrary scheme commands, in this way we could control arbitrary interaction from Julia or Python, e.g. we could even think to have a programmatic interface to edit documents from these programs. All this goes outside the possibilities of the protocol I think (or anyway it would not be implemented in the standard kernels). However we should experiment a bit before getting to conclusion.
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.
1 Like
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.