Examples with hidden lines should be editable

[LukeMathWalker]

Problem

For this issue, there are two types of code blocks:

• Read-only ones, defined via ```rust
• Editable ones, defined via ```rust,editable

Read-only code blocks support the usage of # to hide code from the view that's rendered in the browser:

You can click on the "Eye" toggle to show the hidden lines:

This makes it convenient to break an example across multiple code blocks without repeating content from the previous block (e.g., the definition of UserId in the example above).

Instructors often need to be able to edit code directly on the slide, but we lose the hiding feature if we mark the block as editable:

The UserId definition is shown, even if it was prefixed with # in the source.

Solution

Modify the theme to introduce a new button, next to the "Copy" one, which allows instructors to switch from "Preview" to "Edit" mode.
In "Preview" mode, code is rendered as if the editable attribute had not been included.
In "Edit" mode, all hidden code is shown and the instructor is free to edit.

We won't support going back from "Edit" to "Preview" mode.

[gribozavr]

Modify the theme to introduce a new button, next to the "Copy" one, which allows instructors to switch between "Preview" and "Edit" mode.

Could the "eye" button enable editing as well as revealing hidden code?

When going back from "Edit" to "Preview", should the "Preview" show the original code or the code after the instructor edits?

I'd say it should use the code with the current edits.

[LukeMathWalker]

Modify the theme to introduce a new button, next to the "Copy" one, which allows instructors to switch between "Preview" and "Edit" mode.

Could the "eye" button enable editing as well as revealing hidden code?

It could, if we want to.

When going back from "Edit" to "Preview", should the "Preview" show the original code or the code after the instructor edits?

I'd say it should use the code with the current edits.

There's a challenge in that direction: the hiding # will be stripped when moving from "Preview" to "Edit", so trying to preserve edits will most likely translate into showing all lines when going back to "Preview" mode, thus defeating the purpose a bit.

[djmitche]

While teaching, I find that I "consume" the slide: it starts out nice and compact, and I add lines here and there, edit things so they don't do what they say anymore, etc. By the end, the whole thing is in a bit of a state, but that's OK - it's time to move on to the next slide. So, I don't think going back to "Preview" mode has to re-hide those lines. In fact, I don't see a need for UI to go back to preview mode at all.

[mgeisler]

While teaching, I find that I "consume" the slide: it starts out nice and compact, and I add lines here and there, edit things so they don't do what they say anymore, etc. By the end, the whole thing is in a bit of a state, but that's OK

That is a great way of describing it! It fits with the mindset I've applied when teaching in front of people in a live classroom: the slides are the to assist me in live-coding.

This comment is about the same: #2800 (comment) — I hope the code snippets are good starting points for illustrating all the many different things in the language we want to teach.

This has also made the format frustrating for people who do not see the course with a live instructor: they miss out on all the provoked errors happening during a class 😄 The speaker notes were an attempt at solving this: by providing "hints" to the instructor about what to do, and indirectly also providing them to people who read the material offline.

[LukeMathWalker]

Sounds good—I've amended the solution accordingly then.