Skip to content
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

Implement MiniMessage preprocessor and cleanup parsing #749

Merged
merged 7 commits into from Jun 1, 2022
Merged

Implement MiniMessage preprocessor and cleanup parsing #749

merged 7 commits into from Jun 1, 2022

Conversation

bluelhf
Copy link
Contributor

@bluelhf bluelhf commented Apr 8, 2022

This pull request combines two changes to MiniMessage, one internal and the other external.

On the user-facing side, a new feature is implemented: preprocessing. This is essentially exactly opposite to the existing post-processing in MiniMessage: it's simply a unary operator that is applied to every string input prior to deserialising it into a tree.

On the internal side, this also removes the explicit richMessage parameters from most MiniMessageParser methods, opting to instead deduce the value from ContextImpl where possible. A notable outlier here is the process of escaping tokens, where the richMessage parameter is explicitly required for escaping to work.

allows the parser to infer message content from the ContextImpl that was passed to it, instead of relying on a redundant rich message parameter.
implements a preprocessor for minimessages: behaves exactly like a postprocessor like in existing versions, except the unary operator acts on the raw input strings prior to parsing
fixes StackOverflowError from escaping, introduced by 8671d4b
adds a unit test that checks if basic preprocessing is functional
fixes some issues with a lack of newlines, final keywords, and this-dots
Copy link
Member

@kezz kezz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just the tiniest of nitpicks :p

replace "end" with "start" in preprocessor javadoc
@bluelhf
Copy link
Contributor Author

bluelhf commented Apr 9, 2022

Just the tiniest of nitpicks :p

whoopsies, i guess that's what i get for copy & paste :D

Copy link
Member

@kezz kezz left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for the PR! :)

moves the ContextImpl constructor's closing bracket to a new line

Co-authored-by: Riley Park <riley.park@meino.net>
@zml2008 zml2008 requested a review from kashike April 26, 2022 04:24
@bluelhf bluelhf requested a review from kezz May 26, 2022 12:47
@bluelhf
Copy link
Contributor Author

bluelhf commented May 26, 2022

oh whoops sorry kezz didnt mean to press buttons

@zml2008
Copy link
Member

zml2008 commented May 30, 2022

Out of curiosity, what was your planned usecase for this pre-processing function?

@bluelhf
Copy link
Contributor Author

bluelhf commented May 31, 2022

Out of curiosity, what was your planned usecase for this pre-processing function?

I believe the initial use-case for this was a preprocessor that word wraps the input prior to building the components — the discussion that led to this change is in the #adventure channel on the Kyori discord server

@zml2008 zml2008 self-assigned this Jun 1, 2022
@zml2008 zml2008 merged commit 96afa05 into KyoriPowered:main/4 Jun 1, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants