You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
Background
When testing a PyScript application I noticed that when something was written to
stderr
, the application would append adiv
of classpy-error
to the document. With some digging I determined that this was part of theerror
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 evendonkey
is explained. But others, likedeprecations-manager
andcodemirror
have no explanation as to what they do. The only mention oferror
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 toplugin.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
anddonkey
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 insidecore.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
Pretty sure that should be
!plugin-name
.The text was updated successfully, but these errors were encountered: