Expose code and code blocks' literals via string_content/=. #290
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Thank you! |
|
Thank you @kivikakk and @gjtorikian! |
rossta
added a commit
to joyofrails/joyofrails.com
that referenced
this pull request
May 4, 2024
Replaces markly with commonmarker Markly is a key piece in the original implementation of the ERB-enhanced markdown rendering in Joy of Rails—adapted from phlex-markdown and built on phlex-ruby. * https://github.com/ioquatix/markly * https://github.com/joeldrapper/phlex-markdown According to the markly README, it was originally created as a fork of commonmarker to get access to the parsed markdown Abstract Syntax Tree (AST). The fork is from before commonmarker switched from being a wrapper of cmark-gfm (implemented in C, gfm = GitHub-flavored markdown) to comrak (Rust port of cmark-gfm), also maintained by awesome maintainers. * https://github.com/github/cmark-gfm * https://github.com/kivikakk/comrak It's been nearly a year since markly was released. Just a few days ago, commonmarker introduced access to its AST meaning it supplies the key feature set to make it compatible for markdown rendering enhancements in Joy of rails. I checked it out this morning and reported an issue with code fence parsing early today that has already been fixed as of this afternoon—a Saturday no less—in commonmarker v1.1.2. * Issue: gjtorikian/commonmarker#289 * Fix: gjtorikian/commonmarker#290 * Release: https://github.com/gjtorikian/commonmarker/releases/tag/v1.1.2 Performance benchmarks are reported on commonmarker's README. According to these benchmarks, commonmarker outperforms Kramdown by over 25x. markly outperforms commonmarker by roughly 3x. * https://github.com/gjtorikian/commonmarker?tab=readme-ov-file#benchmarks That said, this changeset provides the minimum changes to switch from markly to commonmarker for markdown parsing. Why change? The energy in the commonmarker and comrak projects is encouraging. I also belive in markly's maintainer, who is awesome, and a terrific advocate for improvements in the Ruby ecosystem. My choice to switch is more about my perception of the momentum of the respective projects. I have no issues with reconsidering this decision at a later time assuming switching back is comparably straightforward.
rossta
added a commit
to joyofrails/joyofrails.com
that referenced
this pull request
May 4, 2024
Replaces markly with commonmarker Markly is a key piece in the original implementation of the ERB-enhanced markdown rendering in Joy of Rails—adapted from phlex-markdown and built on phlex-ruby. * https://github.com/ioquatix/markly * https://github.com/joeldrapper/phlex-markdown According to the markly README, it was originally created as a fork of commonmarker to get access to the parsed markdown Abstract Syntax Tree (AST). The fork is from before commonmarker switched from being a wrapper of cmark-gfm (implemented in C, gfm = GitHub-flavored markdown) to comrak (Rust port of cmark-gfm), also maintained by awesome maintainers. * https://github.com/github/cmark-gfm * https://github.com/kivikakk/comrak It's been nearly a year since markly was released. Just a few days ago, commonmarker introduced access to its AST meaning it supplies the key feature set to make it compatible for markdown rendering enhancements in Joy of rails. I checked it out this morning and reported an issue with code fence parsing early today that has already been fixed as of this afternoon—a Saturday no less—in commonmarker v1.1.2. * Issue: gjtorikian/commonmarker#289 * Fix: gjtorikian/commonmarker#290 * Release: https://github.com/gjtorikian/commonmarker/releases/tag/v1.1.2 Performance benchmarks are reported on commonmarker's README. According to these benchmarks, commonmarker outperforms Kramdown by over 25x. markly outperforms commonmarker by roughly 3x. * https://github.com/gjtorikian/commonmarker?tab=readme-ov-file#benchmarks That said, this changeset provides the minimum changes to switch from markly to commonmarker for markdown parsing. Why change? The libs have similar functionality with regards to what Joy of Rails needs at this time. It feels like with commonmarker it is a little easier for me to figure out how to customize the configuration options. Markly's performance outshines commonmarker but not so much for me to say the tradeoff is painful. The energy in the commonmarker and comrak projects is encouraging. I also believe in markly's maintainer, who is awesome, and a terrific advocate for improvements in the Ruby ecosystem. Ultimately, my choice to switch is more about my perception of the momentum of the respective projects. I have no issues with reconsidering this decision at a later time assuming switching back is comparably straightforward.
rossta
added a commit
to joyofrails/joyofrails.com
that referenced
this pull request
May 5, 2024
Replaces markly with commonmarker Markly is a key piece in the original implementation of the ERB-enhanced markdown rendering in Joy of Rails—adapted from phlex-markdown and built on phlex-ruby. * https://github.com/ioquatix/markly * https://github.com/joeldrapper/phlex-markdown According to the markly README, it was originally created as a fork of commonmarker to get access to the parsed markdown Abstract Syntax Tree (AST). The fork is from before commonmarker switched from being a wrapper of cmark-gfm (implemented in C, gfm = GitHub-flavored markdown) to comrak (Rust port of cmark-gfm), also maintained by awesome maintainers. * https://github.com/github/cmark-gfm * https://github.com/kivikakk/comrak It's been nearly a year since markly was released. Just a few days ago, commonmarker introduced access to its AST meaning it supplies the key feature set to make it compatible for markdown rendering enhancements in Joy of rails. I checked it out this morning and reported an issue with code fence parsing early today that has already been fixed as of this afternoon—a Saturday no less—in commonmarker v1.1.2. * Issue: gjtorikian/commonmarker#289 * Fix: gjtorikian/commonmarker#290 * Release: https://github.com/gjtorikian/commonmarker/releases/tag/v1.1.2 Performance benchmarks are reported on commonmarker's README. According to these benchmarks, commonmarker outperforms Kramdown by over 25x. markly outperforms commonmarker by roughly 3x. * https://github.com/gjtorikian/commonmarker?tab=readme-ov-file#benchmarks That said, this changeset provides the minimum changes to switch from markly to commonmarker for markdown parsing. Why change? The libs have similar functionality with regards to what Joy of Rails needs at this time. It feels like with commonmarker it is a little easier for me to figure out how to customize the configuration options. Markly's performance outshines commonmarker but not so much for me to say the tradeoff is painful. The energy in the commonmarker and comrak projects is encouraging. I also believe in markly's maintainer, who is awesome, and a terrific advocate for improvements in the Ruby ecosystem. Ultimately, my choice to switch is more about my perception of the momentum of the respective projects. I have no issues with reconsidering this decision at a later time assuming switching back is comparably straightforward.
2 tasks
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Hiya! What do you think of this? Currently the
literalmembers of Code and CodeBlock nodes isn't exposed anywhere.The discrepancy between these and
text()-fetchable things is a bit unfortunate on the Comrak side, but it's a side-effect of its legacy (i.e. the implication thattext()means "get me the content of a Text node, and fail if it isn't one") — I see no reason to do the same tostring_contentjust because of what it's backed by currently.Fixes #289.