Render markdown in entity descriptions #1413
Conversation
| to compute a final result of type `b`{=type}. For example, if | ||
| `x`{=snippet}, `y`{=snippet}, and `z`{=snippet} | ||
| are nearby actors, then `meetAll f b0`{=snippet} is equivalent to | ||
| `b1 <- f b0 x; b2 <- f b1 y; f b2 z`{=snippet}. |
There was a problem hiding this comment.
It would be kind of neat if we could introduce variables with markup and then apply them to the rest of the document. Something like:
If `x`{=variable} is a nearby actor, then `give "apple" x` will end all hunger.
There was a problem hiding this comment.
Yes, that would be neat, and not too hard in theory, though it might require a bit of work to plumb the right information around. The basic idea would be that when we typecheck code in backticks we don't simply start it in an empty context, but rather start it in a context that already contains any declared variables (with types like forall a. a).
There was a problem hiding this comment.
@byorgey indeed, I will make an Issue for it. 🙂
@kostmo I think we would need to:
- wrap pure expressions in
return - sequence everything in binds
- unsequence after check
Also some kind of mechanism to hide code, so we can declare variables without cluttering descriptions. I don't know Literate Haskell, so maybe there is a standard way to do so.
|
This is how I debugged it: ghci> -- parse entities.yaml
ghci> em :: [Entity] <- either (fail . prettyPrintParseException) pure =<< decodeFileEither "data/entities.yaml"
ghci> -- format 3D printer descriptions like in TUI
ghci> let Just d3 = L.find (\e -> view entityName e == T.pack "3D printer") em in chunksOf 99 . toStream $ view entityDescription d3And it finally seems to look OK: |
| @@ -181,7 +216,8 @@ fromTextPure :: Text -> Either String (Document Text) | |||
| fromTextPure t = do | |||
| let spec = Mark.rawAttributeSpec <> Mark.defaultSyntaxSpec <> Mark.rawAttributeSpec | |||
| let runSimple = left show . runIdentity | |||
| runSimple $ Mark.commonmarkWith spec "markdown" t | |||
| Document tokenizedDoc <- runSimple $ Mark.commonmarkWith spec "markdown" t | |||
| return . Document $ normalise <$> tokenizedDoc | |||
There was a problem hiding this comment.
Random thought: would there be any value in having a NormalizedDocument newtype whose "smart constructor" performs the normalize function?
There was a problem hiding this comment.
Honestly, if Document used Seq I would consider doing it immediately in (<>), the naive approach here merges the text one-by-one anyway.
The formatting looks great, but now it looks cramped. Can we add blank lines in between every paragraph, like we used to? |
|
CI is failing since there is some code in a docspec test in |
xsebek
force-pushed
the
markdown-entities
branch
from
5db8fa8
to
032c1e2
Compare
@byorgey should be fixed now, I had to rethink the code a little and keep paragraphs for printing. |
|
Btw. the docspec test would not fail if we had But for markdown in Haskell code (e.g. generated entity/robot description) we can use that instance. |
| @@ -208,11 +251,8 @@ unStream = \case | |||
| TextNode a t -> (TextNode a, t) | |||
| CodeNode t -> (CodeNode, t) | |||
| RawNode a t -> (RawNode a, t) | |||
| ParagraphBreak -> error "Logic error: Paragraph break can not be unstreamed!" | |||
There was a problem hiding this comment.
Always nice to get rid of partial functions...
There was a problem hiding this comment.
Indeed, I don't think that paragraph break worked anyway! 😄 It shows that I wrote it before knowing where and how we use the documents.
Co-authored-by: Brent Yorgey <byorgey@gmail.com>
Co-authored-by: Karl Ostmo <kostmo@gmail.com>
|
@kostmo I went ahead and added some colours anyway: I also added a script to run scenarios in order with |
Markdown.DocumentasentityDescriptionchunksOfentities.yaml(mostly types and few outdated snippets)