Glk spec 0.7.1 (and cheapglk, glkterm, glkote, quixe)

(On your Mac. On mine, it’s an apple. On my Swedish keyboard, “å” has its own key.) Unless the game requires special characters to be typed, that’s not really a problem, is it? Or is my understanding that this is a game-specific thing wrong?

I’ve posted an Inform 7 extension to expose the echo/noecho functionality. The included example expands common abbreviations like X into the full word. The example also will say if the interpreter running it doesn’t support the functionality, which you’ll see if you run it in the IDE.

Thanks, Ron.

One request: it would be better if the command were echoed in the Input style, rather than [bold type]. That way it will match the style that was used during editing, and the style used in other games.

I’ve added this comment to the spec re window borders:

The Border/NoBorder was introduced in Glk 0.7.1. Prior to that, all games used the Border hint, and this remains the default. However, as noted, not all implementations display window borders. Therefore, for existing implementations, “Border” may be understood as “your normal style of window display”; “NoBorder” may be understood as “suppress any interwindow borders you may have”.

Is that available in vanilla Inform? I can’t find that even in Glulx Text Effects extension…
I’ll poke around for it. (EDIT: Found it. I’ll see what i can do with it.)

And thank you for the feature in the first place! :smiley:

I now have the [input type] say-phrase working. It was easy, after the necessary research:[code]To say input type: (- glk_set_style(style_Input); -).

when play begins, say “> [input type]start game[roman type]”[/code]But now I have a question. I’d like to give the author a phrase informing him if the input and output types are identical or not. So I used this:To decide if input type differs from roman type: (- (glk_style_distinguish(gg_mainwin, style_Input, style_Normal)) -).But it doesn’t seem to work, as least on Quixe. Does Quixe not implement this? I notice when calling glk_style_measure it returns false on Quixe, but true on Git & Glulxe, and it seems the former function would be composed of the latter. And yet, calling retvalcompare = glk_style_measure(gg_mainwin, style_Preformatted, stylehint_Proportional, compareout); puts a zero in the output variable when it shouldn’t. Matter of fact, I always get a zero in the output variable regardless the interpreter, leading me to believe that I’m doing something very wrong, or a lot of this stuff doesn’t work, either way.


EDIT : nevermind, reading Quixe source tells me it does not. As for the rest of it, I shan’t care.

I see I keep reading these questions late. As you note, it’s just not practical to do this, and it will get less practical in the future (when we move to CSS). Leave the formatting decisions separate from the code.

Implementing style_distinguish could be done in GlkOte… just depends on how much effort is spent on it. Few people seem to want it.

It could be done, but I think it was a design error to begin with, and I’d rather not encouraging people to start relying on it.

I’ve submitted version 2 to the extensions site, with the [input type] style that works just like [bold type] and [italic type]: turn it off with [roman type].

Although I did go ahead and toss in style_distinguish, I put it at the end of the documentation with caveats that not all interpreters support it, and it will tend to return a value saying the styles are the same when it doesn’t know. At worst, the author would be changing the input style when he doesn’t need to, which, without style_distinguish, he would have needed to do anyway: when rewriting the command line so it blends in with other prose, the styling is important so the player knows where to begin reading again after pressing Enter.

If it becomes an issue in the future, we could always go back and implement style_distinguish, but if it doesn’t, so much the better.