Orchil client output ordering collision on SkotOS games like Castle Marrach about orchil

[ChristopherA]

This problem (forcing me to turn off Orchil's local echo) is a candidate for @noahgibbs to work on next week. I'm fairly sure it can be solved in Orchil (say for instance) but if it is an interaction with SkotOS Noah has the skills to figure it out there too.

[noahgibbs]

I had originally thought this was just reversing lines of text, and so it was (perhaps) a race condition. But it turns out it's more interesting than that.

For instance: repeatedly type "clientpref local_echo on" to get five or six lines of "The client preference 'local_echo' is already set to 'on'." Look up above them: there's a prompt (the greater-than sign.)

Now, type "look." The words "You look around" will appear above all the "client preference" output lines, next to the prompt. After that it will figure out that it's supposed to be putting the output lower down, and it will start outputting lines in the right place.

=======

This problem is pretty clearly in Orchil, not in the interaction with the websocket tunnel. That's good! Problems at the border between two different pieces of software are hard.

=======

There is a currentSubElements array, as Orchil figures out where it should currently be printing to. It's basically a stack of open tags (imagine being midway through printing bold+italic entry inside a table.) The more "raw" output modes (printScreened/printUnscreened) interact with it a bit as they figure out where to create Line elements in the browser's DOM using newLineElement().

=====

Pretty sure the problem is the prompt. It's keeping the old prompt around as a printable line in currentSubElements even after printing more lines. But I'm having trouble telling where/how the prompt line gets created.

=====

You can see where the error will happen by examining currentSubElements in the JS console. If you're at the prompt, it contains a single div. You can stick in an identifying chunk of text to verify which div:

currentSubElements[0].innerText += "(yo)"

Now print a couple of 'raw' lines by entering this text in the Gables input area a few times:

clientpref local_echo on

Now check currentSubElements again. There's only one div - the same one it added "(yo)" to. And that's where it's going to print when it can print again. And that's the bug we're seeing.

One good possible solution could be if Orchil figured out we'd printed past the old prompt ("> ") and added a new one. I'll keep looking at it. Once I figure out how the prompt happens, the solution may be obvious.