-
Notifications
You must be signed in to change notification settings - Fork 259
Move the macro registry to MTMathAtomFactory #274
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Merged
Merged
Changes from all commits
Commits
Show all changes
4 commits
Select commit
Hold shift + click to select a range
cd300df
[item 1] Move MTMacroDefinition to MTMathAtomFactory
kostub b7532a1
[item 2] Move the macro table to MTMathAtomFactory and add +addMacro:
kostub 693d029
[item 3] Test macro registration and replacement
kostub 15c71b8
Address review: report a bad macro template as a caller error
kostub File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
🎯 Functional Correctness | 🟠 Major | ⚡ Quick win
Validate parsed top-level parameter atoms.
The character scan rejects valid templates such as
@"\\color{#f00}{#1}"because it treats#fas an invalid parameter. It also accepts#1inside a nested list, althoughMTMathListBuilderonly substitutes top-level parameter atoms. That macro then consumes an argument and leaves the nested#1literal.Initialize the registry before validation. Parse the template and validate the actual
MTMacroParameterAtomlocations and indexes. Allow literal hashes. Reject parameter atoms below the template top level or aboveargumentCount. Add tests for both cases.🤖 Prompt for AI Agents
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Partly acting, in PR #275 rather than here.
Literal hashes — real, and the
\color{#f00}example checks out.NSColor+HexString.m:26expands CSS 3-digit shorthand, so that is a valid iosMath color and+template:referencesOnlyArgumentsUpTo:rejects the template for it. The TeX-correct spelling is##, which must collapse to a single#on expansion (TeXbook Ch. 20). That needs both halves — a validator that accepts##, and a splicer that collapses it — and PR 1 has no splicer:-macroAtomForCommand:hands the template straight to+buildTemplate:, so##would reach-readColoras two characters and yield the color string##f00. Relaxing the validator here alone just moves the failure from registration time to render time. PR #275 has the seam (-spliceTemplate:arguments:), so both halves land there together. Same for the trailing-#case from the CLI run.Nested
#N— declining. It is a real restriction today, but PR #275 lands immediately behind this one and replaces top-level-only substitution with raw-text splicing, so#Nworks anywhere. A validator that rejects nested parameters would be written and deleted in consecutive PRs.The suggested implementation — declining. Validating parsed
MTMacroParameterAtompositions builds on a class PR #275 removes along with the atom-substitution model.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@kostub, thank you for the detailed analysis.Your plan for PR
#275is correct. Literal-hash support requires both validation of##and expansion to a single#. Changing only this validator would defer the failure to color parsing.Raw-text splicing also removes the current nested-parameter limitation. The parsed-atom validation would not be useful after that change.
I will keep this finding open on this PR because the current implementation still rejects valid literal-hash templates. The coordinated fix belongs in PR
#275.🐇
✏️ Learnings added
You are interacting with an AI system.