Skip to content

Conversation

@cameronr
Copy link
Collaborator

Resubmission of #83

This started out as a smaller bugfix but along the way I noticed that sometimes parts were not rendering, so that's the more important issue, from: 4317d0b:

This was a subtle one and it only shows up when we're not collapsing
events so it wasn't caught by the unit tests. I've since modified the
unit tests to also run the replays without collapsing to catch bugs like
this in the future.

If the first version of a part didn't result in something being
rendered, future updates to that part would also not render anything.
This was particularly likely to happen with tools as the first version
of the part is often step-start. Because we didn't think this was a
new part, we called _replace_part_in_buffer but that exits quickly
because the part hadn't been rendered anywhere.

While we could try to call _insert_part_to_buffer in
_replace_part_in_buffer if the part hadn't been rendered, that would
miss some subtle cases around error handling so the correct fix is
consider the part new in on_part_updated if we haven't rendered it
before.

Now, onto the issue that started this PR:

I noticed that embedded codefences were screwing up our rendering. At first, I thought we needed to escape/replace them but then I realized we could use a longer codefence for our outer wrapper. I also realized that we weren't setting the markdown types correctly (markdown should be markdown not md). Setting the codefence to markdown enables render-markdown to render embedded codefences correctly.

Before:

Screenshot 2025-10-28 at 16 16 24

After (the codefence is normally hidden, I just have the cursor there to show the longer codefence and correct type)

Screenshot 2025-10-28 at 21 10 55

It seems like the markdown rendering plugins get confused by nested code
fences so we replace embedded fences with ` ` `
Instead of disabling embedded markdown rendering, we can use a longer
outer codefence.

It did require regenerating all of the test data.
Instead of just using the filename extension, use the neovim filetype
(with some specific overrides). Fall back to the filename extension.

This means we render our markdown sections with `markdown` as the type
instead of `md` and that enables rendering embedded codefences
correctly.

Hopefully the last fix on this :)
Seems like nightly returns text as the type for .txt files which breaks
our tests
This was a subtle one and it only shows up when we're not collapsing
events so it wasn't caught by the unit tests. I've since modified the
unit tests to also run the replays without collapsing to catch bugs like
this in the future.

If the first version of a part didn't result in something being
rendered, future updates to that part would also not render anything.
This was particularly likely to happen with tools as the first version
of the part is often `step-start`. Because we didn't think this was a
new part, we called `_replace_part_in_buffer` but that exits quickly
because the part hadn't been rendered anywhere.

While we could try to call `_insert_part_to_buffer` in
`_replace_part_in_buffer` if the part hadn't been rendered, that would
miss some subtle cases around error handling so the correct fix is
consider the part new in `on_part_updated` if we haven't rendered it
before.
@sudo-tee sudo-tee merged commit 1d799d2 into sudo-tee:main Oct 29, 2025
5 checks passed
@sudo-tee
Copy link
Owner

Perfect,

It's now merged.

Thanks a lot for both fixes in this PR

@cameronr cameronr deleted the fix/missing-parts branch November 4, 2025 21:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants