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

Add strikethrough markdown support #325

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open

Conversation

obask
Copy link
Collaborator

@obask obask commented Mar 21, 2024

Since it's inlined, the extension is added directly to the core module.

@obask obask requested a review from rock3r March 21, 2024 06:41
Copy link
Collaborator

@rock3r rock3r left a 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?

settings.gradle.kts Outdated Show resolved Hide resolved
@rock3r rock3r added the feature New feature or request label Mar 30, 2024
@rock3r
Copy link
Collaborator

rock3r commented Apr 2, 2024

@obask this requires a rebase/cleanup after the latest changes :)

@rock3r rock3r added the markdown This issue impacts the Markdown rendering subsystem label Jul 4, 2024
rock3r added a commit that referenced this pull request Jul 18, 2024
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.
rock3r added a commit that referenced this pull request Jul 19, 2024
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.
rock3r added a commit that referenced this pull request Jul 19, 2024
* 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.
@rock3r
Copy link
Collaborator

rock3r commented Jul 19, 2024

Now that #458 has added inline extensions support, it should be possible to complete the work on this as a separate module

@obask obask force-pushed the feature-strikethrough branch from c0a4392 to 94e7f46 Compare August 14, 2024 17:22
@obask obask force-pushed the feature-strikethrough branch from 94e7f46 to 5e24c92 Compare September 6, 2024 13:46
@obask obask requested a review from rock3r September 6, 2024 13:48
@rock3r rock3r linked an issue Sep 6, 2024 that may be closed by this pull request
@obask obask force-pushed the feature-strikethrough branch from 5e24c92 to 5859872 Compare October 11, 2024 10:29
@obask
Copy link
Collaborator Author

obask commented Oct 11, 2024

I'm not sure if passing markdownProcessor and extensions as separate args works well. Maybe we should just make extensions public or restructure it in some other way.

@rock3r
Copy link
Collaborator

rock3r commented Oct 11, 2024

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

@obask
Copy link
Collaborator Author

obask commented Oct 11, 2024

Given #600 will likely make inline extensions easier, I'd shelve this until that's done. What do you think?

Are you handling #600 yourself? I don't mind waiting, just didn't want stale comments to hang on this PR.

Maybe we can revisit image loading in the meantime

SG! I can do images on or after Oct 16 if that's ok.

@rock3r
Copy link
Collaborator

rock3r commented Oct 11, 2024

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.

@obask obask force-pushed the feature-strikethrough branch from 5859872 to 586c18e Compare November 7, 2024 17:49
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature New feature or request markdown This issue impacts the Markdown rendering subsystem
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add support for strikethrough text in Markdown
3 participants