I’m trying to get a certain visual effect on Glulx using a text grid window. The text grid window must accept a command from the player.
On Git versions 1.3.5 and 1.3.7 (from Gargoyle 2019 and 2023, respectively), it seems that after a line input event the output cursor position of the text grid reverts to Y to 0 (i.e. highest line on the screen) and X to a non-zero value that looks like may be the number of characters typed in the prompt. By comparison, for the interpreter included in the IDE for Linux the behavior seems to be to leave the cursor in the same position that it was prior to the line input request.
Is this intended behavior for Git? Does the Glk specification have anything to say about how this should be handled? (And if it does not, should it?)
I don’t think either of those behaviours is right. From the Glk specification, section 3.5.4 (which is about text grid windows):
When the player finishes his line of input, it will remain visible in the window, and the output cursor will be positioned at the beginning of the next row. Again, if you glk_cancel_line_event(), the same thing happens. The glk_set_echo_line_event() call has no effect in grid windows.
Line input in text grid windows is one of those features that is little used, so is often not well supported. By the way, this is nothing to do with the Git interpreter, really: this is all in the Glk library that the interpreter is linked with, which will be something custom in the case of the Inform 7 front-end, and GarGlk for Gargoyle.
Line input in grid windows is at least somewhat tested. (A couple of the unit tests at https://eblong.com/zarf/glulx/ do it.) However, the spec line about where the cursor is afterwards is not well tested – I can’t remember ever looking at it. So it’s not surprising that bugs have landed there.
Thank you for pointing me to that part of Glk spec, DavidK. It’s good to know what the behavior should be; I may be able to work around non-compliance since line input can’t go past a single line.
I’m not sure how it would even be possible to write a program to test for compliance on this, zarf, unless it were possible to read the cursor position and examine pre- and post-line input values.
Yeah, it would have to be a “do it and then ask the player if if looks right” test. A lot of the I/O tests are. (Print a smiley emoji. Does a smiley emoji appear on the screen? Good!)
As noted by @DavidK, this is definitely a bug in Gargoyle. The code to do the right thing is there, but then something comes along and resets the cursor afterward.
I’ve got a fix in a branch if you’d like to give it a test with what you’re working on. Various builds are available here (in the textgrid-cursor branch), if you have a Github account. Or if you want to do a build, the branch is here.
I thought about that… it could, but only to test the RemGlk library! Or Emglken running headless, I guess. You can’t attach RegTest to an arbitrary interpreter/library combo like the Gargoyle interpreters.