mailing-list for TeXmacs Users

[Marduk BP <address@hidden>]

First of all, thank you Max for your efforts on the Qt GUI! I will try your branch soon 

and report back.

I was thinking that migrating TeXmacs to Racket would be a very good idea. First, it

implements a cross-platform GUI library that uses native widgets. Second, Racket 

is designed for implementing languages. Therefore, we can teach it what Darcy Shen 

calls TIM-Scheme. Racket also has a pretty good interaction with C, an awesome 

plotting library and a very thorough documentation. I think it would solve a lot of

problems and simplify the development.

I also agree with Max on implementing the Jupyter protocol. However, I would do it 

completely independent from Python. Nowadays there are tons of languages that 

have a Jupyter kernel. TeXmacs should become an alternative (and saner and more

powerful) interface for a notebook-based workflow with any language.

Howl is a Lua-based text editor that implements an LPEG parser for each language 

it supports. I think this is a good way to do it. See here for examples: 

https://github.com/howl-editor/howl/tree/ad89244f32060c7532c25226fdf60bf3f4b0d15f/bundles

@Darcy, I would like to suggest that we use GitHub's Projects feature or at least the

Wiki for keeping track of the proposals and the tasks involved in undertaking major

changes to TeXmacs.

For example, I think it would be great to decouple the typesetting system from 

TeXmacs. Then it could become a frontend for other typesetting systems like LuaTeX

or Patoline. And people would become aware of the existence of a great typesetting system :)

@Max It would be great to document how the GUI works, independently from the toolkit, to 

make it easy for others to contribute to its development and potential migration to another toolkit.

Best regards,

Marduk

On Tue, Oct 16, 2018 at 11:23 AM Massimiliano Gubinelli <address@hidden> wrote:

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.