Playing around with example highlighter

[avahoffman]

This builds off of @KatherineCox 's work in #170

• For me it is kinda tricky to visualize where the borrowed text starts and stops in the bookdown. Added a div to "highlight" this
• Third chunk is missing the module settings
• If you define AnVIL_module_settings in one chunk, they persist to the next chunk used. This could be a problem if someone sets variables on chunk 1 but doesn't want them on chunk 2. Added a comment to make that clear and added rm() at the end of the chunks

[github-actions[bot]]

No broken urls! :tada: Comment updated at 2022-11-14 with changes from 44192286b16f583b5646d3bb9f402b5a6a66f9f2

[github-actions[bot]]

:warning: spelling errors :warning: There are spelling errors that need to be addressed. Read this guide for more info. Download the errors here. Comment updated at 2022-11-14 with changes from f7624f450f6646ec41aa5a7b0209ca74c4f9fa59

[github-actions[bot]]

Re-rendered previews from the latest commit:

• See preview of Bookdown here
• See preview of Coursera/Leanpub version here
• Download the preview of .docx file

Updated at 2022-11-14 with changes from 44192286b16f583b5646d3bb9f402b5a6a66f9f2

[KatherineCox]

Awesome, thanks!

Re: persisting settings

• Yeah, I've been trying to figure out the best way to handle them.
• The reason I moved the individual settings inside a list (AnVIL_module_settings) was so that they at least aren't cluttering up the R environment with multiple, miscellaneous names, so they won't bump into anything else in your doc.
• This does still mean that individual modules in the same doc can bump into each other. I've been wondering if we should automatically clear out AnVIL_module_settings at the end of a module (i.e. stick the rm() inside the child doc)?

[KatherineCox]

re: the example divs

• Love this!! I totally agree that we need something to distinguish the instructions from the module content.
• Do you think it's confusing for users looking at the .Rmd file that there's extra stuff around the module code block? I've been hesitant about adding AnVIL_Template-specific things in/around the code blocks because I imagine people will want to copy paste them. This book is serving sort-of dual purpose as both documentation and example.
• Although, looking at your divs, they look really good! I might actually want to keep the surrounding div when I drop the module into a book, because it gives students a visual boundary around the instructions for a particular task. So perhaps it's not actually a concern if people copy the whole thing, div and all.
• In that case, maybe rename the class something like "module" or "instructions" or something, and treat it as part of the AnVIL style (i.e. expect that people will use it in their own books)? It might be nice to have a highlighting box that doesn't come with an image. Might also want to set it so that it doesn't have padding-left: 100px;, since there's no picture.
• Maybe still worth putting some instructions about keeping/removing the div box somewhere

[avahoffman]

The reason I moved the individual settings inside a list (AnVIL_module_settings) was so that they at least aren't cluttering up the R environment with multiple, miscellaneous names, so they won't bump into anything else in your doc.

I agree. I like how you've done this

This does still mean that individual modules in the same doc can bump into each other. I've been wondering if we should automatically clear out AnVIL_module_settings at the end of a module (i.e. stick the rm() inside the child doc)?

This was my original thought. It doesn't work and anvil_module_settings still persists. Maybe because the child environment is separate?

Although, looking at your divs, they look really good! I might actually want to keep the surrounding div when I drop the module into a book, because it gives students a visual boundary around the instructions for a particular task. So perhaps it's not actually a concern if people copy the whole thing, div and all.

That's what I was thinking. If they are left in, no harm no foul.

In that case, maybe rename the class something like "module" or "instructions" or something, and treat it as part of the AnVIL style (i.e. expect that people will use it in their own books)? It might be nice to have a highlighting box that doesn't come with an image. Might also want to set it so that it doesn't have padding-left: 100px;, since there's no picture. Maybe still worth putting some instructions about keeping/removing the div box somewhere

Noted! I can add that. Do you care if I merge #174 into #170 and we work on the same one?

[KatherineCox]

Do you care if I merge my PR and we work on the same one?

@avahoffman Go for it! The only thing I was working on was moving the variables inside the AnVIL_module_settings list, and I think you've finished that for me in this PR by updating chapter 8 :)

[avahoffman]

@KatherineCox great! Thanks for the quick review! :)

[KatherineCox]

I've been wondering if we should automatically clear out AnVIL_module_settings at the end of a module (i.e. stick the rm() inside the child doc)?

This was my original thought. It doesn't work and anvil_module_settings still persists. Maybe because the child environment is separate?

Ah, too bad. I wonder if we could reach up from inside the child environment to the parent with <<-, and set AnVIL_module_settings to NULL?

I considered trying to mess around with withr, but I think the withr code would need to be outside the child doc, which would make things more confusing for users. If we need to handle clearing the settings in the main document, I think your rm() solution is best - people are familiar with rm().

[avahoffman]

we can always change it later if we want to get fancy :)