Open curiousdannii-testing opened 2 years ago
557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:
Comment by zarf :
Added sample source code.
557058:4c095ffd-6d6f-47ce-9e73-77c613347b86:
Comment by zarf :
Compare the behavior in Gargoyle and Quixe (which are correct) to that of the Mac IDE and Mac Zoom (not correct).
Reported by : zarf
Description :
This is a very old problem. I thought it was filed, but it's not.
CocoaGlk's handling of glk_cancel_line_event has always been a mess. It's supposed to leave the player's in-progress command visible, followed by a newline (or just a newline if the player hasn't typed anything). It doesn't. Instead, the player's in-progress command is shifted down to the next line input (ignoring the request_line_event call's ability to specify a pre-loaded input line).
Then there's the glk_set_echo_line_event call. That's a feature, so it doesn't have to be dealt with as part of this. However, note that (a) the bug existed before the glk_set_echo_line_event feature was invented, and (b) CocoaGlk's current behavior doesn't match either the glk_set_echo_line_event(true) or glk_set_echo_line_event(false) rules.
Steps to reproduce :
Additional information :
imported from: [Mantis 1705] glk_cancel_line_event handled wrong