Missing Documentation - Inbuilt Plugins Behavior

Start with docs/user-guide/configuration.md and core/src/plugins.js, then inspect the linked implementation such as core/src/plugins/error.js to inventory built-in plugins and their behavior. Create a documentation page covering each plugin, including which features depend on it, and correct the !plugin-name typo.

Background

When testing a PyScript application I noticed that when something was written to stderr, the application would append a div of class py-error to the document. With some digging I determined that this was part of the error plugin.

Problem

Other than mentioning that there are some inbuilt plugins, we do not go into any detail about what they are. Some of them are obviously, from context, related to features that are mentioned elsewhere in the docs such as py-editor, py-terminal, and even donkey is explained. But others, like deprecations-manager and codemirror have no explanation as to what they do. The only mention of error is that it can be disabled.

Location

The only mention of built-in plugins is under the "Plugins" section of configuration.md, where it links to plugin.js and makes an offhand mention that you can disable inbuilt plugin with an explanation point (e.g. !error).

Proposal

Create a page that goes through the plugins installed, and their behavior/purpose. Some of these plugins may be stub references that reference the actual feature pages, such as py-terminal, py-editor and donkey as separating what the feature does vs what the plugin does may be difficult, but I think having them documented as a) existing and b) essential for that feature to operate would at the very least prevent a help request from someone who is trying to use Terminal, wondering why it isn't working, only to find that they had disabled all inbuilt plugins.

Auxiliary Benefits

Documenting the inbuilt plugins will make it easier for developers to request improvements to the plugins, for example as an obvious improvement it might be better to configure the styling of the py-error class inside core.css rather than hard coding the values, allowing for easier customization of the behavior of the plugin without the need to write a custom implementation.

Nits

... using the !pugin-name convention...

Pretty sure that should be !plugin-name.