Add strikethrough markdown support #325
Conversation
There was a problem hiding this comment.
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?
settings.gradle.kts
Outdated
| @@ -49,3 +50,5 @@ gradleEnterprise { | |||
| termsOfServiceAgree = "yes" | |||
| } | |||
| } | |||
| include("markdown:commonmark-extensions") | |||
| findProject(":markdown:commonmark-extensions")?.name = "commonmark-extensions" | |||
There was a problem hiding this comment.
I'm not sure why this is added here. We don't have such a module in the project, as far as I can see
|
@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 |
obask
force-pushed
the
feature-strikethrough
branch
from
c0a4392
to
94e7f46
Compare
obask
force-pushed
the
feature-strikethrough
branch
from
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
obask
force-pushed
the
feature-strikethrough
branch
from
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. |
Since it's inlined, the extension is added directly to the core module.