Document existing target block behavior#26
Conversation
| If the named target block already exists, Medieval leaves its fence unchanged | ||
| and only replaces the contents. | ||
|
|
||
| That makes it useful when a code block produces Markdown. For example, you can | ||
| create the target block as a `markdown` fence yourself and let Medieval keep | ||
| that fence on subsequent runs: | ||
| > | ||
| <!-- target: rendered --> | ||
| ```bash | ||
| printf '# Title\n\nThis is rendered markdown.\n' | ||
| ``` | ||
|
|
||
| <!-- name: rendered --> | ||
| ```markdown | ||
| ``` | ||
| < | ||
|
|
There was a problem hiding this comment.
I am curious why the example just above this one (lines 42-49) doesn't already make this clear? Can that example me clarified or disambiguated in some way to make it clearer?
With this PR it seems like we are just demonstrating the same thing twice in a row
There was a problem hiding this comment.
You are right, the example below shows something similar: a python block that emits a language-less block.
This documentation is more of a use-case POV: I did not imagine that could already change the language of the emitted block.
| Then (Output written to named target block): | ||
| AssertEqual 'computed', getline(8) | ||
|
|
||
| " === Existing named target keeps its fence === |
There was a problem hiding this comment.
Again it seems to me like this test case is the same as the one line 19? Unless the behavior you are testing is that "when the target block is not empty, the contents are completely replaced". Which is a fair thing to have test coverage for and is different than the first test case. But in that case we should reword/rephrase the test case.
There was a problem hiding this comment.
Indeed. Maybe we don’t need that test at all, it is pretty redundant.
2 participants
Hey gpanders, I hope you are doing fine those days.
As I was pondering about using vim-medieval to generate a dashboard a-la obsidian dataviewjs, I wanted to have that bash snippet output markdown.
Turns out, vim-medieval already does that: one only has to change the codeblock language once and subsequent generations will leave it untouched !
So I asked Codex to generate a vader test to make that behaviour explicit.
Let me know what you think of it,
Best,
Marty