search

Smattr / mattutils

Repository for all my random tools and scripts I use
11 stars 1 forks source link

Bad crecord and terminal mode interaction #28

Closed Smattr closed 7 years ago

Smattr commented 8 years ago

Steps to reproduce:

  1. hg crecord
  2. Select some things to commit
  3. In the middle of writing your commit message in Vim, Ctrl-Z.
  4. fg

At this point, your terminal's corrupted and it's difficult to complete your commit message. This is under Tmux, with crecord and a custom version of hgidentities in play, but I suspect the problem is reproducible with only crecord. At a guess, I would say crecord is using ncurses and doesn't correctly tear it down before launching Vim leading to an inconsistent terminal state, but I haven't investigated.

Smattr commented 7 years ago

Interestingly, doing a similar set of actions in Clink currently prevents Clink repainting the screen when you exit out of Vim. Not sure if the two problems have the same root cause, but might be able to kill two birds with one fix.

Smattr commented 7 years ago

I had some time to dig into this, and it is indeed the same problem. The root cause is that ncurses installs a SIGTSTP handler that it leaves active until process exit. That is, endwin() does not uninstall the handler.

This feels like an ncurses bug to me, but is apparently intended behaviour. It is even documented on the init_scr() manpage, though it took me a while to notice this text because I was looking for interactions with def_prog_mode() and signals. Once you find the right words to feed to Google, you discover all sorts of programs have run into surprising issues as a result of this.

Anyway, once I understood the problem, teaching Clink to work around this wasn't too hard. Will push a cleaned up commit RSN.

Circling back to the original focus of this issue, in the time since I was actively following Mercurial development it seems crecord has been blessed as a bundled extension and this problem was fixed in Mercurial changeset 2cccaf937a7a. This made it into Mercurial 3.5, though the package repos in several of my environments are lagging well behind this. Nevertheless, closing this issue as it now has a solution.