Great idea. We really need a more refined graphical editor. It would be nice also to have a small DSL for programmatic drawing (like metapost, allowing the use of equations to determine position of objects) and a diagram editor (for commutative diagrams).
I’ve accepted the invitation. Should I start adding projects?
I suggest a converter towards the pandoc format. I think it might help a lot.
Yes, indeed. Nice idea.
We can discuss first. Projects should be submitted before 2023/04/25. (The deadline is 2023/04/26 18:00:00 UTF+8)
The number of projects is 2, because there are two mentors registered.
What is the goal to rewrite completely something which already works quite well? You plan to extend/modify the core typesetter? Or it is just a translation of the C++ code in Scala?
You question will be answered here: Proposal: Re-impl `TM->PS/PDF` in modern programming language
I create two another thread to discuss the proposals submitted by me.
Yes, I was meaning this project. I think is not too difficult and will improve substantially out lives. 
Other projects I have in mind are:
[easy] write a converter to and from pandoc from within TeXmacs/Mogan and/or add a exporter to TeXmacs format to pandoc.
[medium/hard] help improve the collaborative features of TeXmacs/Mogan, in particular add user cursors to the live documents and improve performance or add server infrastructure to the live document handling.
[hard] help improve the wasm port of Mogan: the UI should behave a bit differently in the browser: single window app, dialogs which opens as subwindow of the main window. Possibly transform the whole UI to HTML so that it is rendered by the browser and we do not need anymore the Qt code. I’ve started a branch of TeXmacs which does not use Qt for this purpose. It renders the UI via SDL and the internal widget kit of TeXmacs. One could start from there and progressively mirror the UI in the browser via HTML (I have some ideas how to obtain this) until all the UI is migrated to HTML and we can remove Widkit.
A question: where to find documents on the TeXmacs cpp code structures?
I have the same question as @sharkc has. I have been always wanting to start contributing to the project but the documentation is lacking even for end-users, let alone developing…
There are almost none. You can generate the developer’s manual from the Help menu. This is all the docs we have. The rest is the code itself. I might be able to share what I learned looking at the code, which part interests you?
Hard to tell. Generally scheme feels easier to hack even I don’t have a big picture of the codebase. But when I look into the cpp codes, due to lack of knowledge how the big machine is coupled, there are always lots of global states and preprocess macros distracting me from the thing I’m seeking for. I’ll try to look into the dev manual later.
I think you should take up a small project and dig into the codebase starting from it. TeXmacs is really a big program with different parts which have different structures. Is is loosely coupled so you do not need to have a global picture to see how it works, but there are some hacks here and there that can distract you. Also: many things are implemented in Scheme with a low level API in C++. If you want to have a global picture maybe you can give a look at the glue code in src/Scheme/Glue. Personally, after at least 15 years of using and developing for it, I only understand deeply a small part of it. Joris coded essentially all by himself, especially the typesetter and the core UI code.
Maybe GPT4 can help people understand the TeXmacs source?
And if not, maybe contact OpenAI to suggest that they improve their LLM until it can understand the TeXmacs source?
I once participated in OSPP as a student and would like to share some feelings about the program. For students, the program starts from registration which this year was from April 29th to June 4th. During this period, students need to decide which project(s) they want to participate in (multiple projects can be registered for but with priority), communicate with the project mentor, and submit a project proposal. The approval of the proposal is related to whether it passes the review by the organizing committee, but I am not sure how much influence it has. At that time, I chose to write my proposal according to the format of National Natural Science Foundation of China’s grant application.
I suggest that specific tasks should be clearly defined within three months in this proposal and planned on a weekly basis for better guidance from mentors during implementation. When writing my own proposal at that time, I conducted relatively detailed research and planning on each part of what needed completion so that development could start quickly afterwards. Additionally, having a detailed project proposal may help increase chances of approval.
Regarding communication between mentors and students during implementation phase is crucial; different people may have different preferred methods of communication - I only used email and GitHub issue tracking at that time but instant messaging software can also be used if necessary. However, frequency is key - official guidelines recommend communicating at least once per week but more frequent communication might be even better.
During development stage all code contributions must go through pull requests (PRs) before being merged into repository; when finalizing projects PR links are required - while mentors cannot provide direct assistance via code changes there shouldn’t be any issues with minor typo or documentation corrections being made via PRs instead. It also require writing an end-of-project report so make sure enough time is allocated for its completion beforehand; up until one month prior to audit deadline unmerged PRs can still receive improvements and modifications.
That’s all for now, I will add more if anything else comes to mind.
我曾经以学生的身份参加过OSPP的活动，想提供一些关于OSPP 的一些心得。
对于学生来说，这个活动从报名开始，今年具体时间是四月二十九日至六月四日。在这个阶段，学生需要决定参加哪个项目（可以同时报名多个项目，但需设定优先级，我当时只报名了一个项目），并与该项目的导师沟通。报名确认后，学生需要提交项目申请书。这份申请书在一定程度上影响项目是否能通过活动组委会的审核，但具体影响程度我并不清楚。我当时选择按照国家自然基金委的基金申请书格式来撰写这个项目申请书。
我建议在申请书中明确在三个月内具体要完成的内容，并按周为单位为项目进行规划。这样能有利于按时完成项目，并有助于导师规划和指导项目的展开。我在撰写申请书时，已针对要完成的项目细分部分进行了较详细的调研和规划，这样在进入开发阶段后能快速上手。此外，一个详细的项目申请书可能会对通过申请有较大帮助。
我觉得项目实施中导师和学生的交流是最重要的部分，不同人之间适合的沟通方式可能不一样，我当时只使用了 email 和 GitHub issue 这两种方式沟通，当然也可以使用即时聊天软件来沟通。但是最重要的是沟通频率，官方指南中的建议是每周至少一次，我觉得应该要再频繁一些。
在项目开发过程中，要注意所有代码贡献都必须通过PR（Pull Request）的方式合并到仓库中。最终项目结项时需要提供所有的PR链接。官方要求导师不能通过编写代码的方式提供帮助，但我认为对PR进行一些错别字修改和文档修正应该是可以接受的。同时，结项时需要撰写结项报告书，请确保留出足够的时间来完成。在结项后、审核结束前的一个月内，学生仍然可以对未合并的PR进行完善和修改。
暂时就这么多，之后想到了什么再补充。
Let me say that I do not mind if some other mentor what to take up some of the project I proposed. Feel free to step up, I can still be contacted for support / counselling.
@darcy, can you add also this last proposal: Proposal: mechanism to append documents to the generated PDF Thanks!
Let me create a new thread to stage 2.