From ad868818c71e61e53f8374f0ec90d09743e93a8e Mon Sep 17 00:00:00 2001 From: Danila Fedorin Date: Thu, 1 Jul 2021 00:18:39 -0700 Subject: [PATCH] Add some initial thoughts on the implementation. --- src/domain/session/room/timeline/FORMATTED.md | 19 +++++++++++++++++++ 1 file changed, 19 insertions(+) create mode 100644 src/domain/session/room/timeline/FORMATTED.md diff --git a/src/domain/session/room/timeline/FORMATTED.md b/src/domain/session/room/timeline/FORMATTED.md new file mode 100644 index 00000000..1d72a71a --- /dev/null +++ b/src/domain/session/room/timeline/FORMATTED.md @@ -0,0 +1,19 @@ +# Ideas for formatted messages + +* Seems like a good idea to take some + inspiration from [Pandoc's AST](https://hackage.haskell.org/package/pandoc-types-1.22/docs/Text-Pandoc-Definition.html#t:Block). + Then, much like Pandoc AST, we can turn our representation into + markdown in the editor, or HTML in the view. +* As such, we represent formatting by nesting parts + (we'd have a `ItalicsPart`, `BoldPart`, etc.) +* We keep the "inline"/"block" distinction, but only + track it as a property, so that we can avoid adding + block parts to elements that cannot contain blocks + (headers, for instance, cannot contain blocks, but + lists -- themselves blocks -- can). +* When parsing, we may need some sort of "permanent" context: + if we're parsing a header, and we are inside 3 layers of other + "inline" things (italics, strikethrough, and bold, for example), + and we encounter a block, that's still not valid. + * Element seems to not care at all about the validity of what + it's parsing. Do we assume the HTML is well-formatted, then?