add more markup to tutorial objectives prose #1412
Conversation
kostmo
force-pushed
the
feature/more-tutorial-markup
branch
from
b0180bb
to
1faee74
Compare
There was a problem hiding this comment.
Looks good to me 👍
Just so you know putting anything in curly braces will opt out of parsing, you could even do:
Water the `flower`{=Hziulquoigmnzhah}s please.and it would do the same thing - which is nothing, because I did not implement any extra logic for raw inlines, beyond highlighting them in descriptions.
It would be cool to have differentiated color coding for the various annotations |
| @@ -38,7 +38,7 @@ objectives: | |||
| evaluated until needed. In this case, we want to make sure | |||
| that only the correct branch is evaluated. To write a value | |||
| of type, say, `{int}`{=type}, we just surround a value of type `int`{=type} | |||
| in curly braces, like `{3}`. This is why arguments to `build` | |||
| in curly braces, like `{3}`{=snippet}. This is why arguments to `build` | |||
There was a problem hiding this comment.
Why snippet? My understanding is that plain backticks are for anything which is a valid swarm-lang expression. There are a bunch of other similar places where I think you added snippet unnecessarily. We defintely don't want to use it if we don't have to since snippets are not checked whereas plain backticks are parsed and typechecked.
There was a problem hiding this comment.
Right, I failed to read the docs 👓 .
@kostmo that is definitely the intention. 🙂 Right now, any garbage in curly braces will stop parsing and the conventions are not enforced (also not set in stone yet). Once we have the nice |
xsebek
force-pushed
the
feature/more-tutorial-markup
branch
from
1faee74
to
21ab251
Compare
|
@kostmo it seems you were quite thorough, I only found a few tidbits. 👍 |
kostmo
force-pushed
the
feature/more-tutorial-markup
branch
from
68a1d77
to
a516597
Compare
Closes #1411