Suppressing line break after cancelling line event?

I finally fixed the bug I mentioned in my last post, by copying the primary input buffer into the secondary.

Now I’ve found a new thing to be annoyed about. When clicking the compass rose to enter a command, most interpreters will first print a line break before echoing the new command, like this:

> north The temporary barrier is locked. We’d need to set the code-lock to the right number. rather than

> north The temporary barrier is locked. We’d need to set the code-lock to the right number. This has always been the case on every interpreter except Zoom, which is what the Mac Inform IDE uses. But for some reason it hasn’t really bothered me until now.

As far as I can tell, the Glk API specifies that there should be a line break printed when cancelling a line event, and the only way to avoid this is to turn off line input echo with glk_set_echo_line_event() if the interpreter supports it. So the only way to do what I want seems to be to turn off line input echo permanently at the start of the game and then write lots of code to “manually” echo all input except when clicking on a graphic link.

Am I right? Is there really no simpler way?

That is the situation. If you don’t want the interpreter to handle echoing, you have to handle it.

(Zoom is definitely wrong in its behavior, but it hasn’t been updated since before I added the glk_set_echo_line_event feature.)

One possible workaround is to leave the echoing behavior as-is, but print a prompt before the synthetic command:

> north
The temporary barrier is locked. We’d need to set the 
code-lock to the right number.

There’s an extra blank prompt line but at least the command isn’t sitting there naked.

Could you call glk_set_echo_line_event just before canceling the event and then call it again afterwards? Or when the spec says all subsequent events does that mean it’s too late?

Yeah, it’s too late. You’re supposed to know what your plan before you request line input.

Thanks! Actually it was easier than I feared to hack input echo into VM_ReadKeyboard(), though it remains to be seen what subtle bugs it causes.

Actually, Spatterlight seems to behave like Zoom in this respect.

I pushed the new input echo suppression code. You’d think it would break something, but it seems to work fine so far.

Now we just have to make CM run on those new Emglken interpreters in Lectrote.

Does it not run in Lectrote? It should!

Btw, I never really got around to figuring out how to profile CM. But now I want to so that I can see which of Lectrote’s Glulx terps is fastest.

Git will show a *** fatal error: Out-of-bounds memory access *** at startup. Glulxe will just show an eternal spinning “Loading…” compass.

Well, we wrote that code that shows the total play time at the end if there is a “testing” file present. I guess that would work if we can make the game actually run.

Edit: I can make it start on Git if I disable Startup Precomputation. But it won’t register pressing the enter key when trying to answer the initial question.