Vim cursor disappears after running crystal scripts in Vim subshell

[chaniks]

Mac OS X 10.11.6 / Crystal 0.19.2 and master

Reproduce:

1. Run vim
2. Type :!crystal and press Enter
3. Press Enter

Now the cursor disappears.

Details:

When already editing some files in Vim (not always but sometimes, usually with syntax-enabled files), some lines become invisible. (e.g. mbox file?)

In some cases, the cursor shows up again if I move the cursor with keyboard, but sometimes it doesn't.

Running _crystal-compiled executables_ in Vim subshell produces the same problem.

Also tested with a fresh new account and on a different Mac machine (same OS version though), but the results were same.

Workaround

After running the script,

• <CTRL+Z> and then fg (return to parent shell and come back)
• press : and press <Enter> => does not fix the vanished lines
• or any other behavior that refreshes screen or resets the cursor position of Vim.

[ozra]

Cursor color commands not reset at end of crystal output?

[asterite]

@chaniks Are you using vim-crystal? If so, this should probably be reported there (this repository is about the compiler and standard library). Thank you!

[chaniks]

@asterite Yes. But it is not vim-crystal dependent. (The machines that don't have vim-crystal installed also produce the same result.)

[asterite]

Maybe related to #2713, though I'll have to know what these crystal executables you use do (do they replace the buffer or modify it?)

[chaniks]

@ozra I guess there is a little bit more.

The (visible) position of the cursor also changes, and before returning back to Vim main screen, Vim waits for user to press Enter and the cursor is visible at the right position. It disappears when I get back to the main screen.

This is what I've found while research: mitmproxy/mitmproxy#357 (comment)

[chaniks]

@asterite actually, now it does nothing at all. (I tried to narrow it down)

$ touch a.cr
$ crystal build a.cr

and !./a in Vim produces the same result.

By the way, what I was mostly worried about was that the compiler itself is also a crystal-compiled executable. Do you have to compile all from the first version again to fix this?

[RX14]

@asterite Maybe the crystal stdlib shouldn't treat ttys differently until it needs to. I'm pretty sure crystal changes tty modes and settings in the stdlib by default, and I think that this should be explicit.

[chaniks]

@RX14 hmm.. I don't know about the history on this, but current way of handling tty sounds cute good, or maybe okay. This might be just a small bug, compared to its advantages.

[chaniks]

I guess I found the problem.

The bug appears 0.7.2, which introduced STDIN, STDOUT, and STDERR as FileDescriptors in prelude. (0.7.2:src/main.cr which is now master:src/kernel.cr)

It overwrites the blocking option of fcntl depending on isatty. I am not sure if it is intended and is required, but preserving the original value seems to fix this bug. (Please double check. I had to compile various versions of crystal in random order during the test. I cleaned it up as much as possible, but I still doubt.)

However, writing a fix for this issue may require some design considerations. I am too new to crystal to do that.

Whoever can handle it, please go on.

[asterite]

@chaniks Exactly! This is an exact duplicate of #2713, as I mentioned before, so I'm closing this. I still don't know what the fix for this is...