Evaluate ModeMath designs for CSharpMath font data and editing

[Happypig375]

Goal

Evaluate specific designs from SummaticLtd/ModeMath that could simplify or improve CSharpMath. This is a bounded architecture study, not approval for a wholesale rewrite.

Use ModeMath commit 1ba976e as the comparison baseline. ModeMath is an MIT-licensed F#/.NET library using SkiaSharp; its bundled fonts retain their separate GUST and SIL OFL licenses.

Designs to evaluate

• Generated OpenType MATH data in MathFontData.g.fs, compared with Precompute bundled math-font data instead of parsing it at runtime #191 and CSharpMath's runtime Typography dependency.
• The immutable typed expression tree in MathAtom.fs and parallel cursor tree in Cursor.fs, compared with CSharpMath's Atom and Editor models.
• Tentative closing brackets and autosizing in Editor.fs, compared with Create and edit automatically sized bracket pairs #82.
• Cursor-aware layout for empty slots and decorated atoms in Placed.fs, compared with Size the editor caret to the surrounding expression #158 and the current inability to edit some accented/decorated structures.
• Typed recognition/insertion of functions and radicals, compared with Recognize typed function names in the math editor #83.
• Core size and maintainability. The initial estimate is about 4,925 lines across 11 F# core files including generated data; remeasure generated and handwritten code separately rather than treating line count alone as a design result.

Deliverables / acceptance criteria

• Build both libraries at the pinned revisions and record the exact commands and environment.
• Produce a feature matrix for parsing, LaTeX round trips, layout/rendering, bracket completion, navigation, decorated-atom editing, undo/redo, and public API compatibility.
• Compare cold font initialization, parse/layout/render time, editor-update time, allocations, and package size on a small shared corpus.
• Separate generated from handwritten code when comparing size and complexity.
• For each design above, record one decision: adapt incrementally, prototype further, or reject, with compatibility and maintenance rationale.
• Record code and font licensing obligations before copying any implementation or asset.
• Link existing issues where they already cover accepted work and create narrowly scoped follow-up issues only for genuinely new work.

The result may be posted as a structured comment or repository design note; production changes are not part of this investigation issue.

[Happypig375]

@charlesroddie Do we still want to keep the manual review process of CSharpMath given that I will do lots of AI automation on it? The only real reviewer available is you, and I don't think you want to review all the C# changes.

[charlesroddie]

Interesting problem, and a lot of repos are running into review as a limiting factor. I use AI review (claude + github copilot) and it has become very good. But human review needed for big questions like should a feature go in, does a PR hurt maintainability.

It's also true that there is a shortage of reviewers. You are saying I'm the only other maintainer now? @FoggyFinder ? Since I am using ModeMath, I don't depend on CSharpMath, but I can still be a maintainer if needed.

The first distinction I have made in the past, and which may be useful now, is that there is a core of CSharpMath (which I took to be the core library/editor/skiasharp renderer) and a periphery (including symbolic algebra, example projects in all possible dotnet frontends). The periphery has not been given much review. So that could just not have any github reviewer requirement at all. I believe CODEOWNERS can achieve this.

For PR reviews to be eaiser, how about this structure: the PR title and description should be very concise, contain a simple feature description, describe any costs of the change including extra code or complexity that may make maintenance harder in future, say what the AI review process was (beyond github copilot which is assumed, e.g. "reviewed by claude"). A human reviewer can then read this, skim through the diff, and that should be enough for a decision.

Those are my ideas but interested to see what yours are @Happypig375 .

[Happypig375]

What you say makes sense. I'm a ChatGPT Pro user and Codex reviews are very good too. I'll PR an AGENTS.md in with your instructions later.

As for GitHub Copilot, it's too expensive as it uses API prices of Claude and GPT instead of subscriptions.

@FoggyFinder indicated unavailability last time I tagged him, and I think @hflexgrig only now got the collaborator invitation.

[FoggyFinder]

I check github daily at least few times so feel free to request review - I can skim through changes fairly quickly and approve if needed.

Time isn't issue, concentration is.

llm are quite good and catches more than human being. But sometimes they miss obvious things or do dumbest mistakes like leaking private keys.

So basically I agree with @charlesroddie - if changes aren't related to "core" then merge as long as ci is green and llms are happy.

[Happypig375]

GPT-5.6-Sol checks keys by itself and seems trained to never leak a private key - smaller models might not have this guardrail though.

[Happypig375]

@FoggyFinder Do some reviews of all the PRs when you available

[charlesroddie]

@FoggyFinder Do some reviews of all the PRs when you available

It's not me you atted but this is not fair. Even if the PRs are good, the volume is too much. But the PRs look like AI slop. I looked at one PR: #326 . It had some very bad signs:

• Only one commit. You would expect some back and forth and more commits in an ai writer/human director & reviewer/ai reviewer process.
• The images output are ludicrous. There has obviously has been no review of this by you, and AI review would have caught it too.

My guess based on this one PR is you are testing an AI process, it failed owing to lack of human and AI supervision and review, but you didn't notice.

[Happypig375]

@charlesroddie There are second looks before merging - see the latest ones in https://github.com/verybadcat/CSharpMath/pulls?q=is%3Apr+is%3Aclosed

AI seems to work less well on its own on edits that aren't purely code - like ones that require visual imagery, so I'll go through them again one by one

Some PRs are actually good to go already - for example #294