Skip to content

Add range information to SymbolNode and ConstantNode#3522

Closed
serso wants to merge 1 commit intojosdejong:developfrom
serso:parsed-exp-range
Closed

Add range information to SymbolNode and ConstantNode#3522
serso wants to merge 1 commit intojosdejong:developfrom
serso:parsed-exp-range

Conversation

@serso
Copy link

@serso serso commented Aug 27, 2025

The parser knows the position of the nodes in
the original text and can as well return this
information in the node objects.

This is useful when implementing the MathJS syntax highlighting in a rich text editor.

One drawback of adding "range" property to the node object is that two semantically equal nodes might not be equal when parsed from different strings as their "range" properties might differ. This caused some
failures of assert.deepStrictEqual in tests.

The parser knows the position of the nodes in
the original text and can as well return this
information in the node objects.

This is useful when implementing the MathJS syntax
highlighting in a rich text editor.

One drawback of adding "range" property to the node
object is that two semantically equal nodes might not
be equal when parsed from different strings as their
"range" properties might differ. This caused some
failures of `assert.deepStrictEqual` in tests.
@serso
Copy link
Author

serso commented Aug 27, 2025

Hey, I've created this PR to get some early feedback from the maintainers/community. What do you think about the change? Is it upstreamable?
I'm using MathJS as a spredsheet/calculator engine and want to use the information from the library's parsing procedure to implement syntax highlighting.
The PR needs some improvements, in particular some tests are still failing as assert.deepStrictEqual takes into account the new field.

@josdejong
Copy link
Owner

Thanks @serso , adding information about the positions of the tokens in the original expression would be useful nice indeed!

A few years ago, a PR was made implementing this same idea: #2796. The PR is quite mature already but unfortunately was never finished. I think we can go in two directions from here: either read up on #2796, use it for inspiration and work out a new PR. Or start from #2796, work out the open ends, and rethink it where needed. Would you like to pick this up and if so what approach do you prefer?

@serso
Copy link
Author

serso commented Sep 3, 2025

Thanks for the tips. I'll check out the old PR.

@serso
Copy link
Author

serso commented Oct 17, 2025

I have followed up on the old PR, see #3557

@serso serso closed this Oct 17, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants