glkote
glkote copied to clipboard
erkyrath
GlkApi notes
GlkApi's gli_get_line doesn't add a NULL byte.
Also, just to check my understanding of the spec, if it reads a line break, that line break should be copied to the buffer and then a NULL, not replaced by the NULL, right?
Huh, yeah. That's a fun thing to not notice for decades.
if it reads a line break, that line break should be copied to the buffer and then a NULL, not replaced by the NULL, right?
Right.
Towards the bottom of glk_window_close it tries to set box = content_box;, but there is no content_box in the file.
This must mean that that branch is never run. And so the whole keydamage_flag stuff is unncessary?
It looks like glk_cancel_line_event doesn't convert non-Latin1 characters into ?s for a non-unicode buffer.
It's also not very clear whether non-Latin1 characters should be converted before or after echoing.
GlkApi trims the input to the buffer length before echoing it. Is this required by the spec, or can I echo first, then trim?
Also, RemGlk doesn't support partial inputs at all?
The GlkOte docs say that terminator keys can only be escape or func1-12, but GlkApi allows any special keycode. GlkApi also doesn't ignore return?
As RemGlk only allows what the GlkOte docs say, I'm going to take this as a GlkApi bug rather than a GlkOte docs mistake.
But the Glk spec seems to just say it could be any special keycode...
glk_gestalt says buffer windows instead of grid windows support mouse input.
I can't see anywhere that dialog.js cleans up temp files. Or it could just use sessionStorage for temp files.
TIL: most OSes don't clean up temp files automatically either!
@erkyrath Thinking about the terminator keys again... I assume you originally designed it to be able to do what the Z-Machine spec says? But there's quite a lot of inconsistency between the terps. Is there any reason not to support as much as possible though?
GlkApi: all special keycodes RemGlk: escape and func1-12 Garglk: escape and func1-12 Windows-Glk: escape, pageup/down, func1-12