Repository navigation
Evaluate ModeMath designs for CSharpMath font data and editing #273
Description
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.fsand parallel cursor tree inCursor.fs, compared with CSharpMath'sAtomandEditormodels. - 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.
Activity
Happypig375 commentedon Aug 30, 2026
@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.
[-]Investigate what we can learn from ModeMath[/-][+]Evaluate ModeMath designs for CSharpMath font data and editing[/+]charlesroddie commentedon Aug 30, 2026
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 commentedon Aug 30, 2026
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 commentedon Aug 30, 2026
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 commentedon Aug 30, 2026
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 commentedon Aug 31, 2026
@FoggyFinder Do some reviews of all the PRs when you available
charlesroddie commentedon Aug 31, 2026
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:
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 commentedon Aug 31, 2026
@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
Happypig375 commentedon Aug 31, 2026
@charlesroddie I guess I should tell it to open draft PRs to not make the false impression that they are expected to be slop-free then
Happypig375 commentedon Aug 31, 2026
@charlesroddie #326 has been fixed
charlesroddie commentedon Sep 1, 2026
I.e. ready for review but the others are still marked ready for review so I suggest converting everything to drafts and picking out those that you personally consider ready.