Plug-ins: the kind-mismatch error reads correctly for importers and exporters, and a failed import leaves the open document alone

A plug-in of the wrong kind now gets "is a plug-in of kind `exporter`, not an importer", with rows in every complete-message catalog. The importer failure test also covers an open, edited document. docs/plugins.md states that Open Recent does not remember Open With's importer or parameters.
This commit is contained in:
dotCooCoo
2026-11-08 09:13:30 -08:00
parent 80770bb5fe
commit 3d80b6a133
27 changed files with 86 additions and 29 deletions
+4 -1
View File
@@ -69,7 +69,10 @@ extensions with that importer (on the web, File › Open's picker opens instead)
desktop the importer runs off the UI thread, and a run that takes a while shows a progress window with Cancel, which
stops it. An importer
with parameters, given no `params`, asks for them in a dialog of the same kind once the file is picked, and its Open
button opens the file; File › Open runs an importer with its parameters' defaults. **File › Open** of a `.wasm` file installs
button opens the file; File › Open runs an importer with its parameters' defaults. Open Recent opens a file the way
File › Open does: it does not remember the importer or the parameters given to Open With. A built-in format reads the
file if one can, and otherwise the first importer by id that lists its extension reads it with its parameters' defaults.
**File › Open** of a `.wasm` file installs
a plug-in too (on the web this is how plug-ins get in). A heavy filter asks before it is installed, and runs in the
background ([below](#heavy-filters)). A plug-in that lists permissions asks for them before it is installed
([below](#permissions)).