I’ve got Parchment integrated into my IF mapper (https://fweep.xyz), but there’s still one missing piece, which is autosave/restore. It seems jarring for the map data to autosave and the story data not to. I’ve been diving into Parchment and Lectrote and Quixe to see what exists, but right now my head is just swimming with glk/remglk/glkote/emglken/emscripten/etc and I can’t keep it all straight. It seems like just integrating Quixe by itself might be straightforward, but I really want the multi-platform support of Parchment or Lectrote. I’m not sure extracting Lectrote from Electron is an easy process (but maybe I could at least learn something from understanding how it works), and I’m not sure where to start with Parchment. Anyone have any advice on where to start on this task? I sure could use it.
In Lectrote, each interpreter handles its own autosave behavior (if it supports it at all). When you see a Glulx game autosaving in Lectrote, that’s just Quixe’s autosave feature.
In other words, “integrate Quixe by itself” is actually the right way to think about this, because that’s what Lectrote does!
I can’t speak to Parchment, which is itself a multi-interpreter and therefore more complicated. I stick to maintaining Quixe.
I took your advice and integrated Quixe for Glulx only, and it works great 
Autosaves in Glk land need to be handled by three pieces of software: the VM, the Glk library, and if separate from the Glk library the IO library (like GlkOte). In Jan last year I changed Parchment’s Glk library from GlkApi to RemGlk-rs, but RemGlk-rs doesn’t have autosave support yet. Autosaves are still something I intend to add, but they will take a lot of time to implement. Sorry.
If you wanted to support both Glulx and Z-Code autosaves in your project, then you can go back to an old release of Parchment (which still used Quixe): Release Parchment 2024.12.31 · curiousdannii/parchment · GitHub
Alright, that clears up a lot of mystery. Thanks.