Original handling of snippets only worked if the current selected theme was a staticTheme. This now fully merges all snippets through the theme chain no matter what the top-level theme is. So user themes built on 5ePHB can benefit from 5ePHB snippets too.
User input of user snippets will be a later PR, but merging them into static snippets is now supported.
Themes contain both CSS and Snippets. The brewRenderer only cares about the CSS, but other components need the Snippets. Better to have the parent "editPage", etc. load the theme bundles and pass them down to each child that needs it, rather than trying to pass from the child up.
This also fixes the `metadataEditor.jsx` not being able to change themes live; A new theme bundle is now loaded when a new theme is selected, instead of only the first time the BrewRenderer mounts.
Also renamed to "fetchThemeBundle"
Each theme in the theme chain, including user brews, must use the same renderer. When moving to V4 or future versions, it will be important to distinguish which themes are compatible with each other
Ended up being a fairly straightforward change. A few ternaries got smooshed or inverted. Passes builtin and local tests. Need to compare on the test instance.
The button displays the *next* state of the toggle. IE, if the current state is locked ( Live scrolling is active ) the icon is unlock with a corresponding mouse-over.
It may be desirable to invert this.
This catchs CTRL-HOME, CTRL-END, and mouseclicks.
It tests for changes on arrow keys and enter.
Not sure if it's the best way to do this, but it works quickly on a large, crappy brew.
now has refs `editorWrapper` and `editor`-- the former includes the snippet bar and codemirror editor, and the latter includes only the codemirror editor.
This adds the User Brew themes, where applicible, to the /new path.
This adds a semi-graceful failure to the metadata panel when a Brew Theme is declared as used but is not present.
More gracefully handles loading with themes not present.
David Bolack