Handle terminal resizing

[DavidGriffith]

I thought that the Z-machine could not handle having the terminal size changing. Apparently it can because Fizmo seems to have no trouble doing this.

[DavidGriffith]

It seems that Fizmo's resizing goes hand-in-hand with the history scrollback. Frotz doesn't have this.

[tkorvola]

I've dabbled with your resize branch a bit. Here is what I've found out on this so far:

• Some curses implementations such as ncurses handle SIGWINCH if the application doesn't. They arrange for the next refresh() or getch() to update the library state, including COLS and LINES. getch() then returns KEY_RESIZE to alert the application.
• Not all curses implementations do this. The standard way is for the application to install a SIGWINCH handler and call endwin(); refresh(); upon receiving the signal. refresh() then updates COLS and LINES.
• It is likely unsafe to call curses from a signal handler; the handler should just set a flag that regular execution will check.
• Screen contents after endwin(); refresh(); are undefined. Ncurses does not seem to change them but according to its manual (resizeterm) some implementations clear the screen. For reliable results the application should reprint the screen fitted to the new size.
• Setting the relevant header flags should make the game adjust new output to the screen size. The interpreter is on its own with reprinting though. It may be possible to query curses about the old screen contents (before endwin()) if they are not saved in the application.
• It seems that SIGWINCH is not sent to stopped applications. It would be prudent to handle SIGCONT and check for resize also there. Or just assume that resize has occurred.

[DavidGriffith]

FYI, gcc is complaining about how you did stuff like this:

/* void unix_do_scrollback(void);  /* ux_screen.c */

[DavidGriffith]

@tkorvola, you seem to have a better handle on doing things with curses the Right Way. Would you like to be assigned this issue?

[tkorvola]

Why not. I'll take a look - no guarantees what progress I'll make. I don't really have experience on curses programming, particularly not on alternative implementations - I am using ncurses just like I suppose pretty much everyone else these days.

I commented away some function declarations when I noticed that the functions don't actually exist. I don't know why they were there - was there some plan to implement them at some point?

[DavidGriffith]

I think those functions appeared before I got custody of Frotz.

[DavidGriffith]

It looks like Github isn't letting me do what I'm trying to do regarding assigning you to this task. Could you just continue with experimenting with the resize branch in your cloned repo?

[tkorvola]

Yes, that was the plan in any case.

[tkorvola]

Resizing appears fairly easy and curses will do most of the work when the terminal dimensions increase. endwin(); refresh(); reprints the screen starting from the top left corner, excess areas are left blank. Problems start when the terminal shrinks.

If the number of lines shrinks, we should probably reprint a region around the cursor, typically the last lines, instead of the topmost lines. The cursor position will change, and functions that think they know where the cursor is will be surprised. cursor_y will need to be updated as well as any local variables tracking the cursor position (at least in os_read_line).

The line editor only allows commands that fit on a screen line. What if the terminal becomes narrower and the currently edited command no longer fits?

Aren't there Frotz versions supporting window size changes out there? Say, WinFrotz? Maybe I need to check out what they are doing.