(This is a distant priority, but I'm writing it down because the subject came up.)
You're supposed to be able to extend a Glulx interpreter with a custom I/O system (2 is Glk, higher values are available). Quixe doesn't make this particularly easy.
We could support this with a plugin architecture by adding a default case to every switch (curiosys) { ... }. (Remembering that 0 should always do nothing.) The code generation at (e.g.) line 2197, 2222, 2258 would have to also generate calls to the plugin. The plugin basically has to offer an API for "shove characters here".
Also replace direct and generated calls to Glk.glk_put_jstring() with plugin calls.
(This is a distant priority, but I'm writing it down because the subject came up.)
You're supposed to be able to extend a Glulx interpreter with a custom I/O system (2 is Glk, higher values are available). Quixe doesn't make this particularly easy.
We could support this with a plugin architecture by adding a default case to every
switch (curiosys) { ... }. (Remembering that 0 should always do nothing.) The code generation at (e.g.) line 2197, 2222, 2258 would have to also generate calls to the plugin. The plugin basically has to offer an API for "shove characters here".Also replace direct and generated calls to Glk.glk_put_jstring() with plugin calls.