-
Notifications
You must be signed in to change notification settings - Fork 42
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
Add strikethrough markdown support #325
base: main
Are you sure you want to change the base?
Conversation
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.
The PR looks good, but I would prefer if we didn't have extensions bundled in the core module. I know it's a bit more work to fully support inline extensions, but the skeleton should already be there. Can you extract the strikethrough code to an extension-gfm-strikethrough
module?
@obask this requires a rebase/cleanup after the latest changes :) |
Tests have been updated to match the new behaviour, that's closer to the CommonMark one. Inline extensions are now possible, but not tested. This makes #325 possible, since the extension now can be moved to its own module. Note: please don't look at the test changes. They're _verbose_ and are only there to ensure CommonMark specs compliance.
Tests have been updated to match the new behaviour, that's closer to the CommonMark one. Now we don't carry unparsed inline Markdown anymore, but rather we fully parse it in advance, so rendering it later is easier and doesn't require running parsing in the UI anymore. This is a tradeoff in memory usage for speed of rendering, and it makes sense in the context of most Markdown text being static and only parsed once, then kept on screen. Inline extensions are now possible, but not tested. This makes #325 possible, since the extension now can be moved to its own module. Note: please don't look too much at the test changes. They're _verbose_, and are only there to ensure CommonMark specs compliance.
* Make Markdown processing not optimised by default The vast majority of Markdown use cases will be displaying static text, so trying to optimise for an editor-like scenario is counter-productive. This PR sets the flag to false by default. This commit also cleans up the MarkdownProcessor code and kdocs. * Make Markdown blocks implement equals and hashcode The value classes we used to use would rely on the CommonMark models for this, but none of the CommonMark models actually implement equals() and hashCode(), leading to issues in tests and in Compose. * Cleanup links in JewelReadme Now links point to GitHub, so the app doesn't crash when you click them. * Add equals/hashcode to inline Markdown entities, too Tests have been updated to match the new behaviour, that's closer to the CommonMark one. Now we don't carry unparsed inline Markdown anymore, but rather we fully parse it in advance, so rendering it later is easier and doesn't require running parsing in the UI anymore. This is a tradeoff in memory usage for speed of rendering, and it makes sense in the context of most Markdown text being static and only parsed once, then kept on screen. Inline extensions are now possible, but not tested. This makes #325 possible, since the extension now can be moved to its own module. Note: please don't look too much at the test changes. They're _verbose_, and are only there to ensure CommonMark specs compliance. * Add inline extensions mechanism This is not tested, and not used yet, so it may or may not need tweaks down the line. We'll find out when we implement the first extension.
Now that #458 has added inline extensions support, it should be possible to complete the work on this as a separate module |
c0a4392
to
94e7f46
Compare
94e7f46
to
5e24c92
Compare
...otlin/org/jetbrains/jewel/markdown/extension/strikethrough/StrikethroughRendererExtension.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/jewel/markdown/extension/strikethrough/StrikethroughRendererExtension.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/jewel/markdown/extension/autolink/StrikethroughProcessorExtensionTest.kt
Outdated
Show resolved
Hide resolved
.../main/kotlin/org/jetbrains/jewel/markdown/extension/strikethrough/CustomStrikethroughNode.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/jewel/markdown/extension/strikethrough/StrikethroughRendererExtension.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/jewel/markdown/extension/strikethrough/StrikethroughRendererExtension.kt
Outdated
Show resolved
Hide resolved
...otlin/org/jetbrains/jewel/markdown/extension/strikethrough/StrikethroughRendererExtension.kt
Outdated
Show resolved
Hide resolved
5e24c92
to
5859872
Compare
I'm not sure if passing |
Given #600 will likely make inline extensions easier, I'd shelve this until that's done. What do you think? Maybe we can revisit image loading in the meantime |
Are you handling #600 yourself? I don't mind waiting, just didn't want stale comments to hang on this PR.
SG! I can do images on or after Oct 16 if that's ok. |
Yes, I have started. It will probably take me a couple weeks-ish to finish tho as I have a busy rest of the month. Ok for the timing on images. We can also catch up in London. |
5859872
to
586c18e
Compare
Since it's inlined, the extension is added directly to the core module.