Dear all

On 16. Oct 2018, at 09:21, Marduk BP <address@hidden> wrote:

Before adding something to the Qt code, it is necessary to fix the 

memory leaks that crash TeXmacs. Once it is safe and stable, one

can even consider adding QCustomPlot. With plotting, syntax highlighting

and code completion, TeXmacs would become a pretty good alternative

to the Jupyter Notebook.

I have a branch with a half-working Qt5 version of TeXmacs. You can find it on my github (mgubi).

The only problem with this (as far as I can see) is that the widgets in the main menu in the mac version (e.g. the color widget) does not work since Qt5 do not have custom widget facility for main menus on mac. It should work find on Linux and WIndows, so maybe somebody could give it a try. Also Dark mode (in Mojave) is currently not properly supported by Qt5.

As for the proposal to add a more heavy dependence on Qt I’m not really into it. In my opinion Qt very much bloated for what TeXmacs really needs and it is starting to cause many problems (see breaking our code between Qt4 and Qt5). We use a very small subset of it and I do not think TeXmacs should rely on more.

My long term goal is to have the Cocoa layer back on the Mac (we will need anyway at least Cocoa menus since the support in Qt/mac for custom menus is shitty and this is source of many of the crashes). And also I’m evaluating to try out a wkwidgets plugins which would have the advantage to be leaner.

As far as competition with Jupyter notebooks, to me the right way to go is to implement the jupyter protocol so that TeXmacs can talk directly to the python core as a TeXmacs session. This would be really great and not very difficult and would not rely on Qt. The plotting has to be done in Python, that would avoid us to carry on code which we cannot reliably maintain. (matplotlib seems ok for that)

Also for the syntax highlighter: maybe having a way to use the Kate syntax files within TeXmacs would be better. One has to keep in mind that TeXmacs has his own C++ programming ecosystem (lists, strings, etc…) bringing in Qt code in areas not directly connected to the bridge between the internal gui representations and the Qt library would spread incompatible data structures (eg:  Qt list vs. texmacs lists etc…) which would need converstions, etc… very painful. We should try to keep the internal coding of the program consistent and allow other paradigms only at the interface with external libraries. 

Again, much of the problem is not to bloat the code so to make long term maintenance more difficult.

Best

Max

On Sun, Oct 14, 2018 at 3:59 PM Darcy Shen <address@hidden> wrote:

Great!

I have another idea. Just introduce the highlight part of kate.

see https://github.com/KDE/syntax-highlighting

This library only depends on Qt 5.

---- On Fri, 24 Aug 2018 17:26:25 +0800 Marduk BP <address@hidden> wrote ----

Unfortunately, given the way it works at the moment, you have to add a file your_language.cpp to /svn_root/src/System/Language/ based on one of the other language files there and compile TeXmacs.

In order to make this friendlier and more efficient, it is necessary to expose the packrat parser included with TeXmacs to the Guile frontend.

I am also interested in this feature. I hope to find time soon to work on it.

On Tue, Aug 7, 2018 at 1:51 AM, Mitran, Sorin <address@hidden> wrote:

Hello,

Does anyone know the steps required to add another programming language to Insert->Code with syntax highlighting support?

Thanks.