This repository was archived by the owner on Sep 10, 2025. It is now read-only.
fix(markdown): simplify markdown formatting api #157
Merged
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.
I started working on displaying Markdown again after a while. With a new round comes a new look at the Markdown handling/formatting API I created previously. As it often happens it felt.. more complicated than it needed to be:
setMarkdownStringdefined as an extension onTextViewwas cute in theory, but because it's not a top level helper method, but has to be used with a class instance it resulted in a convoluted usage pattern:with (markdown) { textView.setMarkdownString(content) }. And it required passing the handler/formatter all the way to where the view is.MarkdownStringwhich in theory is just a general value holder, but in practice lives in a sync engine module, so while it's not in principle, in practice it is or feels tied to the sync engine. Also, looks like all usages before this new addition in Notes, actually had to artificially create this "sync engine" wrapper, just to use Markdown formatting.The change to a method that converts a string with markdown formatting to
Spanned:TextView, but I think it's a good trade-off that we have to for example explicitly set link movement methods or add more explicit binding from ourTextViews to Markwon,Note
By the way this fixes a long standing bug in Collections, where collection story excerpts weren't clickable. So to open a collection story you had to click on the card anywhere except on the excerpt (which was usually the largest part). This is an issue we fixed ages ago, where the default link "movement method" eagerly eats all clicks on a
TextView, even outside of links and even if there are no linksSo this is the trade-off of switching away from Markwon auto-magic. We switched to our own link movement method, which has had a fix/workaround for this issue for ages.
References
PR Checklist
Setup:
Conventional Commits standard
Review: