Julia programming language

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.


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:

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.

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.

1 Like

I wouldn’t have thought about it without your suggestions, either :slight_smile:

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 :smiley:

EDIT: centered now

1 Like

Can you center better the document? I would like to post it on the twitter account. :slight_smile:

Here’s two more attempts, in landscape:

Or as a series:

1 Like

Thanks! I posted the landscape picture.

1 Like

Progresses with the plugin (and with my understanding of Julia…)


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.

1 Like

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.