all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: "Andries E. Brouwer" <Andries.Brouwer@cwi.nl>
To: 14491@debbugs.gnu.org
Subject: bug#14491: emacs -nw doesn't always restore the terminal screen
Date: Tue, 28 May 2013 20:22:01 +0200	[thread overview]
Message-ID: <20130528182159.GA22032@jp> (raw)

Sometimes after exiting "emacs -nw" the cursor is left
in the middle of a former terminal buffer, so that one
has to search for the bash prompt among former buffer text.
Sometimes the cursor position is OK, but the screen is not restored.

On my old computer I saw this sporadically, now I see it regularly.
It feels like a timing issue.

Probably the same issue was reported by Vincent Lefevre
in bug#10959 for emacs 23.3. That was also my working emacs,
but I verified that emacs 24.3 has the same issue.

Running the session under script shows what emacs sends to the
xterm pseudoterminal.

When all works as expected one sees something like
^[[?12l^[[?25h^[[?12;25h^[[>4m^[[48d^[[?1l^[>^[[?12l^[[?25h^[[?1049l^[[39;49m^M
upon exit. In the cases that fail it is something like
^[[?12l^[[?25h^[[?12;25h^[[>4m^[[48d^[[K

The essential difference for the purposes of this bug is ^[[?1049l,
the "te" capability ("rmcup" in terminfo terms), that restores
terminal state.

First solution:

Replace the invocation "emacs -nw --no-splash file" by
"emacs -nw --no-splash file; tput rmcup".
Now all is fine.

Second solution:

The "^[[>4m" here is from xterm-remove-modify-other-keys
which is attached to kill-emacs-hook. If I remove it,
I no longer see the problem. (Maybe only the timing is changed,
maybe this really helps. One could imagine that the same terminal
is approached via several buffered output streams, and that a
second simultaneous invocation of a terminal write kills the first.)

The ^[[?1l^[>^[[?12l^[[?25h^[[?1049l^[[39;49m^M" comes from
tty_reset_terminal_modes();
It contains a fflush (tty->output); Adding an fsync() there
does not help. An additional sleep for a few seconds does not
help either.

Third solution:

If I add another
OUTPUT_IF (tty, tty->TS_end_termcap_modes); fflush (tty->output);
at the end of tty_reset_terminal_modes();
I no longer see the problem.

Proper solution: no idea.
What sources of concurrency are there? Does emacs use threads?
Does emacs write to several file descriptors that ultimately
refer to the same pty?

Since this is tested via script, the properties of xterm do not seem
to play a role.

Andries





             reply	other threads:[~2013-05-28 18:22 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-05-28 18:22 Andries E. Brouwer [this message]
2013-08-02 16:56 ` bug#14491: emacs -nw doesn't always restore the terminal screen Andries E. Brouwer

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20130528182159.GA22032@jp \
    --to=andries.brouwer@cwi.nl \
    --cc=14491@debbugs.gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.