Don't let the player be stuck

[leroivi]

I don't know if this software is only meant to be a supervised lesson or if its goal is to be also a self-training tool so maybe that issue is not meaningful.

As a beginner will come to make many mistakes, he will fill his terminal print with many unsuccessful tries and errors. It can happen to the point where the player won't see the introduction header anymore. To someone that does not have the habits of getting help commands and don't quite remember the gsh commands, it can stuck him.
I think the software should print a reminder of the gsh help command constantly, I see three ways :

• A small frame prints the reminder constantly in the top-right corner of the terminal (or a fixed first line), I think it's the most user-friendly way to print the reminder but I don't see how to achieve this without a TUI program and it would be to much work for a small detail.
• The reminder is abbreviated at the end of each input prompt, but I think it would take to much space for the few times it is useful.
• The reminder is printed to stdout after a period of inactivity, I think it's the best compromise but the timer value would be arbitrary and some user can be discouraged before seeing the message.

Also, the user can makes mistakes that leads to heavy computational operations that stuck him (in particular with grep initiation), so I think it would be useful to introduce the ^C buttons to cancel the command. Once again, a beginner would need to remember it in a distress situation, so the software might remind that with one of the solution mentioned before.

[phyver]

Your third solution would probably bring more problems from newcomers, as the message would garble the current command being typed.

Your second solution could work. What about printing a message (like the message being printed if you leave Gameshell's directory structure) reminding about gsh help, but only during the first couple of missions. It could depend on an environment variable so that it is easy to switch on / off.

[phyver]

I'm not sure about what you're proposing for the "heavy" initialization that can take place. If those are stopped, the whole mission is probably not going to work, and you would have to manually run a gsh reset to bring it back to a usable state.

I don't remember if I'm actually trying to do it, but it would make more sense to ignore ^C for those!

[leroivi]

You're right, I didn't think that it could happen while the user is typing, moreover a beginner would type slowly so it has more chances to happen.

Good idea to print the reminder only during a couple of first missions, that effectively where I saw a beginner needs it, after that she got the habits.

I was not talking about the initialization, I think it's greatly done with a waiting animation, and I understand that interrupt it could lead to unstable state.
I was talking about the command the user can run : I have run a wrong grep command in the maze, and it took more than a minute before I think "it can't be right" and canceled it with ^C. I think that it can happen to a beginner while the ^C has not been introduced, and it will block his terminal so he can't even type a help command to understand how to get out of that. Plus, the process notion and the SIGTERM are learned in some missions, so I think it would be easily explained.

[phyver]

You're right, I didn't think that it could happen while the user is typing, moreover a beginner would type slowly so it has more chances to happen. Good idea to print the reminder only during a couple of first missions, that effectively where I saw a beginner needs it, after that she got the habits.

Can you try the devel branch and tell me what you think?

About ^C: you are completely right. At the moment, it is only introduced "indirectly" with ^Z, fg and bg. Having a mission specifically about ^C as a way to interrupt a running command would be a very good idea. I'll add that to my todo list...

[phyver]

Oh, and I just pushed a new mission about ^C on the devel branch. It was more fun than the other stuff I had to do today... That's mission 19 if you want to try it.

[leroivi]

Can you try bd3de20 (on branch devel) and tell me what you think?

Actually I think it's a bit scary :/ it feels like a warning message as if I did something wrong. I think it is because of the yellow color. It might looks better with a dark and friendly color so that looks optional, like grey, darkblue or purple.

Also I was more thinking of something like this (inspired by StackOverflow)

prompt() {
    PS1=$(printf "%*s\r%s\$ " "$(tput cols)" "(type 'gsh help' to get some help)" "[mission $(gsh pcm)]")
}
PROMPT_COMMAND=prompt

(we should add the translation system, the conditional printing, and maybe some dark color to this)

Oh, and I just pushed a new mission about ^C on the devel branch. It was more fun than the other stuff I had to do today... That's mission 19 if you want to try it.

Nice ! The translation was missing but I guess you're waiting to validate the original text and maybe a batch of mission before proceeding the translations. I didn't understand well the mission in the first place, I was looking what he was mumbling, waiting to interrupt him as soon as his sentence make sense. Maybe his mumblings can vanish in some "......................" so he's finally quiet ? Also, I would add a NOTE in the goal to say that technically ^C is sending a SIGTERM to the current process, as this notion is approached in "processes" chapters with the kill command.

[phyver]

Probably better not to put any color on the message, that way, I don't have to think about background color and such.

I'm not sure I like the idea of putting the message on the far right. My students sometimes play in very wide terminals, and I'm not sure they'd really see it. Plus, if it's on the same line as the prompt, then people will wonder what happens when the commands you're typing reach the message.

The best is probably to keep it simple: a single line message, like yours, above the prompt during the first couple of missions.

And yes, the control-c mission is very much work in progress. I've made it so his mumbling slowly transform into '...'. You have to wait at least couple of seconds before interrupting the process, and you have to interrupt it before it stops. I'm not sure I want to make that explicit in the goal as it is explained by the process itself.

I'm still unsure about the "story". Don't hesitate to give any idea that would make it more interesting than putting Merlin in a trance... :)

I've (forced) pushed some commits on the devel branch if you want to try.

[phyver]

I just officially pushed 2 new missions (missions 19 and 20, just after the xeyes mission) on master. If you want to try them...