From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Daniel McClanahan Newsgroups: gmane.emacs.bugs Subject: bug#18931: 24.4; delete-frame suspends tty when running emacs on virtual terminal Date: Mon, 3 Nov 2014 01:07:07 -0600 Message-ID: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=089e015382cad3277e0506eeff31 X-Trace: ger.gmane.org 1414999160 18549 80.91.229.3 (3 Nov 2014 07:19:20 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Nov 2014 07:19:20 +0000 (UTC) To: 18931@debbugs.gnu.org Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 03 08:19:13 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XlBuy-0003Yv-0l for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Nov 2014 08:19:12 +0100 Original-Received: from localhost ([::1]:60686 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBux-0002d4-J8 for geb-bug-gnu-emacs@m.gmane.org; Mon, 03 Nov 2014 02:19:11 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60489) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBus-0002cw-Pm for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:19:08 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlBup-0007q1-QO for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:19:06 -0500 Original-Received: from debbugs.gnu.org ([140.186.70.43]:49524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBup-0007pw-KK for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:19:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XlBup-0001hk-Di for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:19:03 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Daniel McClanahan Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 03 Nov 2014 07:19:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 18931 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Original-Received: via spool by submit@debbugs.gnu.org id=B.14149990976459 (code B ref -1); Mon, 03 Nov 2014 07:19:03 +0000 Original-Received: (at submit) by debbugs.gnu.org; 3 Nov 2014 07:18:17 +0000 Original-Received: from localhost ([127.0.0.1]:46732 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlBu3-0001g4-Tb for submit@debbugs.gnu.org; Mon, 03 Nov 2014 02:18:17 -0500 Original-Received: from eggs.gnu.org ([208.118.235.92]:57157) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XlBjk-00005f-Mh for submit@debbugs.gnu.org; Mon, 03 Nov 2014 02:07:37 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlBje-00057N-GY for submit@debbugs.gnu.org; Mon, 03 Nov 2014 02:07:31 -0500 Original-Received: from lists.gnu.org ([2001:4830:134:3::11]:35466) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBje-00057J-Eh for submit@debbugs.gnu.org; Mon, 03 Nov 2014 02:07:30 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:58872) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBjd-0007db-9P for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:07:30 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XlBjc-00056n-6N for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:07:29 -0500 Original-Received: from mail-yh0-x231.google.com ([2607:f8b0:4002:c01::231]:42866) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XlBjc-00056d-2t for bug-gnu-emacs@gnu.org; Mon, 03 Nov 2014 02:07:28 -0500 Original-Received: by mail-yh0-f49.google.com with SMTP id t59so4629896yho.22 for ; Sun, 02 Nov 2014 23:07:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:from:date:message-id:subject:to:content-type; bh=OtXMEJfGcgxGjBs/ddsE55JQd7P3Vl5wCLZOZMBLwg8=; b=aoiRnU6Y/ne8yEq6pS5f2YEp3UrJ4rXrAN9IRQbEfibIGKVtgxc/ycqgcwGGnuerhT ovPG+pJkNX6t10+T2uVoXeqU66f35f2gr+f0BDZvb/x5yCWMUp0O2UIWLh4+xFhPwrmr xT1ac1xV5GcHqzKcvOuYAXFnDpQW7rfPTXd4DZP0kqGlvR08RTh+eftBY6lWOufc2O53 AqGzLQ+fv3Q8KumvNoMLYcrz29TR8dbTax7WynZlheMynR54Lw9Aq7c5rUGm0K/Zy2Jn mP8eqp5bZFN13ed+1wJudxh4e10K2YbQqX7nceGAR5qT/21T2xxKtoeLbZK1OdpSOQmb 1+4w== X-Received: by 10.236.16.162 with SMTP id h22mr26197896yhh.71.1414998447563; Sun, 02 Nov 2014 23:07:27 -0800 (PST) Original-Received: by 10.170.163.86 with HTTP; Sun, 2 Nov 2014 23:07:07 -0800 (PST) X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Mailman-Approved-At: Mon, 03 Nov 2014 02:18:14 -0500 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:95417 --089e015382cad3277e0506eeff31 Content-Type: text/plain; charset=UTF-8 When delete-frame is called, emacs eventually runs the function server-delete-client, defined in server.el. In server.el, there is an unless clause stating in the comments "Delete the client's tty, except on Windows". This assumes that if the user is using emacs with multiple frames, those separate frames are running in separate ttys. However, when I typically use emacs in multiple frames, those multiple frames are simply in separate virtual terminals within an X session. As a result, this behavior (deleting the tty) is vexing for me, since it makes closing a frame also crash emacs, which is running in the same tty (the tty is suspended and when unsuspended with fg, emacs displays text entered literally (^X and the like are displayed, for example), but does not respond to M-x or other keybindings). Obviously, this does not occur (I've checked) if: 1) Emacs is running graphically. 2) Emacs is running in gdb. To make this occur: 1) Run emacs -nw in a virtual terminal window and start server. 2) Run emacsclient -nw in another virtual terminal. 3) Run delete-frame on the client and observe the behavior in the original emacs terminal window. When I commented out that unless clause and rebuilt emacs the behavior disappears, so I'm confident I've correctly diagnosed the issue. I've created a defcustom in my local version of the development bzr branch of server.el to allow the user to specify whether this behavior should occur, defaulting to nil which enables the current behavior. Would sending a patch of this be acceptable, or does the project wish to simply continue the current behavior of server-delete-client? --089e015382cad3277e0506eeff31 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
When delete-frame is called, emacs eventually runs the fun= ction
server-delete-client, defined in server.el. In server.el, there is= an unless
clause stating in the comments "Delete the client's = tty, except on
Windows". This assumes that if the user is using ema= cs with multiple frames,
those separate frames are running in separate t= tys. However, when I typically
use emacs in multiple frames, those multi= ple frames are simply in separate
virtual terminals within an X session.= As a result, this behavior (deleting the
tty) is vexing for me, since i= t makes closing a frame also crash emacs, which is
running in the same t= ty (the tty is suspended and when unsuspended with fg,
emacs displays te= xt entered literally (^X and the like are displayed, for
example), but d= oes not respond to M-x or other keybindings).

Obviously, this does n= ot occur (I've checked) if:
1) Emacs is running graphically.
2) E= macs is running in gdb.

To make this occur:
1) Run emacs -nw in a= virtual terminal window and start server.
2) Run emacsclient -nw in ano= ther virtual terminal.
3) Run delete-frame on the client and observe the= behavior in the original emacs
terminal window.

When I commented= out that unless clause and rebuilt emacs the behavior
disappears, so I&= #39;m confident I've correctly diagnosed the issue. I've created a<= br>defcustom in my local version of the development bzr branch of server.el= to
allow the user to specify whether this behavior should occur, defaul= ting to nil
which enables the current behavior. Would sending a patch of= this be acceptable,
or does the project wish to simply continue the cur= rent behavior of
server-delete-client?
--089e015382cad3277e0506eeff31--