Hello. Don't this happen in any ncurses app? Do you know whats the signal sent when resuming with fg command..?

Using whatever the latest sc-im package is on FreeBSD, I experience the same. Suspending puts the shell prompt wherever my cursor happened to be, and resuming doesn't refresh the screen either.

In addition to the above, even after refreshing the screen following suspension, I don't get a visible cursor in my shell.

I don't usually have trouble with other programs, e.g. vim, less, etc.

I adore sc-im, but I also have this problem. Other ncurses applications handle it (C-Z then fg) fine. I believe that the signal that is sent by the fg command is SIGCONT, though I don't know much about the semantics of it. I would imagine that it would suffice to create a SIGCONT handler that automatically redraws the screen, but I'm not sure.

If that is the case it would be easy to fix!

Please update to latest commit in freeze branch and try this!!

No dice yet for me on FreeBSD:

On 87242d8

Try resuming..

Typing fgENTER in this situation did restore the screen.

However, if I first reset the screen with clearENTER or Ctrl L and then type fgENTER again, the shell only prints scim and nothing else happens. When I then press Ctrl LENTER again, scim reappears.

@andmarti1424 Thanks, it does resume cleanly for me on Ubuntu 17.10!

However, when I suspend it in the first place it doesn't leave the terminal in a usable state. When I press C-Z, it doesn't clear the screen and my terminal emulator's cursor is invisible. I can resolve this by typing reset, so it's workable in its current state. Should I open a separate issue about this? It's not quite the same problem. I don't think that this behavior is new either, I just notice it more because I actually use scim with suspend/resume job control now.

It wont be neccesary. I will try to fix it this afternoon.

Could you please try again with latest commit?!

@andmarti1424 Works like a charm, thank you so much!

@jimu? @sjmulder ?

The issue is fixed for me. Suspend and resume work great - just like vim.

Thank you!

A few loose ends:

1. make reports:

   dep_graph.c:526:9: warning: variable ‘evaluated’ set but not used [-Wunused-but-set-variable]
     int evaluated = 0;
         ^

2. version unchanged:

    > scim --version
    Sc-im - version 0.6.5

3. scim starts with "syntax error" on the second row

4. scim --version outputs "syntax error"

I dont know about that "syntax error". I dont have that problem. Anyone else have that?
The version is still the same, yes. Didnt change the version number.

It seems i had an invalid line in my .scimrc file. My mistake.

Perhaps we could change the error message from syntax error to something like this?

syntax error in ~/.scimrc on line 1

That is not possible since thats a parser error and dont know the caller (in this case (.scimrc)
in other cases could be another file, or just user input, or may be script!

Thanks, works for me too. There is one small quirk: the prompt is printed halfway down the line, perhaps the cursor column needs to be reset or such?

@sjmulder, whats shown in your picture shouldnt happen. It should clean the sc-im spreadsheet and leave everything black (or your terminal background color) Whats your OS? You have latest ncurses or it is old?

That's what happens if I launch sc-im, then immediately suspend.

I'm using almost up-to-date FreeBSD, with system libraries, except libxslwriter which comes from a package:

$ uname -rs
FreeBSD 11.1-RELEASE-p4

$ ldd scim
scim:
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x800887000)
        libm.so.5 => /lib/libm.so.5 (0x800ae5000)
        libxlsxwriter.so.0 => /usr/local/lib/libxlsxwriter.so.0 (0x800d10000)
        libthr.so.3 => /lib/libthr.so.3 (0x800f4e000)
        libc.so.7 => /lib/libc.so.7 (0x801176000)
        libz.so.6 => /lib/libz.so.6 (0x80152e000)

To build, I have added the following to the top of the Makefile:

CFLAGS   = -I/usr/local/include -I/usr/include
LDFLAGS  = -L/usr/local/lib     -I/usr/lib
LDLIBS   = -lncursesw

Other programs like vim are using the same ncurses version.

I did some further testing:

• On FreeBSD, all curses program stay in scrollback on suspension. So whether It should clean the sc-im spreadsheet and leave everything black depends on the system.

• Suspending scim on FreeBSD / sh puts the prompt on the middle of the line (as shown in the screenshot) but otherwise works.

• Suspending scim on Ubuntu / bash works well.

• Suspending scim on Ubuntu / sh puts the prompt on the middle of the line but also unresponsive to any input so I have to forcefully close the terminal. Blindly typing fg Enter didn't help
  either.

It seems then that the problem is somehow specific to the combination of scim and sh. (Although I have not tested any combinations other these listed.)

@sjmulder, please take note that VIM does not use ncurses. Yes, I believe the shell has its own interpretation of the SIGTSTP signal.. Regardin sc-im ncurses is paused and resumed as it should acording to ncurses documentation. I believe there is nothing more we can do about this inside sc-im.

The vim binary I use is linked against ncurses but maybe it's not used for the UI. In any case, the terminal locking up completely can hardly be proper behaviour, not? It's easy to reproduce on Ubuntu:

bash$ sh
$ ./scim
^Z
<type anything>

It sure should not lock the terminal. What I say is that is probable has nothing to do with scim. I believe its more a shell issue. That steps to reproduce it, do not fail in my arch instalation. Just to see if anything changes..could you please try the same steps with mocp (moc package) or any other ncurses app?

With top, which uses ncurses:

/usr/bin/top:
        libncursesw.so.8 => /lib/libncursesw.so.8 (0x800830000)

It works well:

[1]   Suspended               top
$

Again, this doesn't clear the screen entirely on my system, by design, but the prompt works properly.

I find it hard to believe that both FreeBSD's sh and Ubuntu's sh are broken.

If it locks the terminal thats a behaviour of not reseting ncurses before suspending. Perhaps it uses another signal? Its hard to me to analyse this since I dont have freebsd and ubuntu right now. Could you do a simple C program and see whats the signal send by the OS when you press ctrl z?
SIGSTOP? SIGTSTOP? I am current catching the latest. May be it should caught both.

Perhaps both SIGSTOP and SIGTSTP should be caught. Anoyher test in your system would be replacing SIGTSTP with SIGSTOP and see if the behavior is the same..

@sjmulder , could you test the above? thanks!

@andmarti1424 I can't do such testing right now, sorry. If it helps, this is the control mapping on my FreeBSD system:

$ stty -a
...
cchars: discard = ^O; dsusp = ^Y; eof = ^D; eol = <undef>;
        eol2 = <undef>; erase = ^?; erase2 = ^H; intr = ^C; kill = ^U;
        lnext = ^V; min = 1; quit = ^\; reprint = ^R; start = ^Q;
        status = ^T; stop = ^S; susp = ^Z; time = 0; werase = ^W;

And on Ubuntu on WSL:

$ stty -a
...
intr = ^C; quit = ^\; erase = ^?; kill = ^U; eof = ^D; eol = M-^?; eol2 = M-^?;
swtch = M-^?; start = ^Q; stop = ^S; susp = ^Z; rprnt = ^R; werase = ^W;
lnext = ^V; discard = ^O; min = 1; time = 0

Ubuntu’s signal(7) says: “SIGSTOP cannot be caught, blocked, or ignored” hence I doubt that’s the issue.