texmacs / gsoc

This Github Repo is intended for GSoC 2020 only

GNU TeXmacs

GNU TeXmacs is a free wysiwyw (what you see is what you want) editing platform with special features for scientists. The software aims to provide a unified and user friendly framework for editing structured documents with different types of content (text, graphics, mathematics, interactive content, etc.). The rendering engine uses high-quality typesetting algorithms so as to produce professionally looking documents, which can either be printed out or presented from a laptop.

The software includes a text editor with support for mathematical formulas, a small technical picture editor and a tool for making presentations from a laptop. Moreover, TeXmacs can be used as an interface for many external systems for computer algebra, numerical analysis, statistics, etc. New presentation styles can be written by the user and new features can be added to the editor using the Scheme extension language. A native spreadsheet and tools for collaborative authoring are planned for later.

TeXmacs runs on all major Unix platforms and Windows. Documents can be saved in TeXmacs, Xml or Scheme format and printed as Postscript or Pdf files. Converters exist for TeX/LaTeX and Html/Mathml.

Documentation

GNU TeXmacs is self-documented. You may browse the manual in the Help menu or browse the online one.

For developer, see this to compile the project.

Contributing

Please report any new bugs and suggestions to us. It is also possible to subscribe to the [email protected] mailing list in order to get or give help from or to other TeXmacs users.

You may contribute patches for TeXmacs using the patch manager on Savannah or using the pull request on Github. Since we are using SVN on Savannah, PRs won't be directly accepted on Github. We will git apply the patch into SVN repo if the PR is accepted. And we will close the PR and change the title to [SVN] xxx after applying the PR.

gsoc's Issues

Be more specific about the tasks involved in developing a Jupyter interface

I believe that leveraging Xeus, a C++ implementation of the Jupyter kernel protocol, what Texmacs needs in order to become an alternative interface to the official web-based one is an implementation of the notebook, which involves writing Scheme, C++ , and a Texmacs stylesheet. Of course, one can use the IPython kernel to test the interface.

Some of the tasks involved are:

• Write an importer/exporter of notebook files.
• Refactor the syntax highlighting support in Texmacs. Adding lexers for new languages should not require recompiling the program.
• Implement modal cells: normal mode and insert mode like in vim.
• Mark multiple cells, cut and paste cells.
• Use the same keyboard shortcuts as the Jupyter notebook.

Are the conversion options between programming languages and TeXmacs unwanted?

Hi. I'm an applicant of GSoC 2020 and I was trying some import/export options. (just some ready-ups for improvement). The options read that I can convert my TeXmacs doc to programming language source code, like C++, Scala or something. But I don't know what the differences between these.
However I tried to export .cpp, .py and .java file. The only difference that I found is about their file suffixes, and everything in export content is the same.
Actually I don't know what's the relationship between TeXmacs and programming languages. I think the truth is that TeXmacs regards the conversion as "convert to plain text".
In my point of view, these conversion options to different languages can be removed, or, as an alternative, can be summarized as "export to code file".

Unit Test-one idea about TeXmacs

Unit testing, also known as module testing, is a test for correctness testing of program modules. It can effectively help developers reduce bugs, improve development efficiency, ensure code compatibility, improve code quality, and better maintain code.
The program is initially intended to introduce Google's open source C++ unit testing framework-Google Test. Google Test's testing technology is very mature, and the feedback results are also user-friendly, so it is convenient for people to get started faster, and also for developers to analyze and solve code problems.
Based on this, I built a subproject-collection, initially integrated the unit test framework Google Test. After a simple test, the results are correct. Some students have been interested in this subproject and submitted a pull request and several issues after analysis. So I think this idea can be implemented very well.
Also, a few months ago, I saw a TeXmacs memory technology (https://www.douban.com/doubanapp/dispatch?uri=/group/topic/105715564&dt_dapp=1&dt_platform=com.douban.activity.Qq_session). Perhaps through unit testing analysis, TeXmacs can be further optimized, such as the memory allocation technology of the open source project jemalloc.