GNU bug report logs - #11102
24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process

Previous Next

Full log

View this message in rfc822 format

From: Juanma Barranquero <lekktu <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 11102 <at> debbugs.gnu.org, Chong Yidong <cyd <at> gnu.org>, dmoncayo <at> gmail.com
Subject: bug#11102: 24.0.94; C-x C-c from a client frame sometimes kills the whole Emacs process
Date: Thu, 12 Apr 2012 20:11:38 +0200

On Fri, Mar 30, 2012 at 19:45, Eli Zaretskii <eliz <at> gnu.org> wrote:

> It most probably is.  Juanma, could you take a look, please?

A little after current_frame is forced to 0 on Windows (in the -c / -t cases):

#ifdef WINDOWSNT
  /* Emacs on Windows does not support GUI and console frames in the same
     instance.  So, it makes sense to treat the -t and -c options as
     equivalent, and open a new frame regardless of whether the running
     instance is GUI or console.  Ideally, we would only set tty = 1 when
     the instance is running in a console, but alas we don't know that.
     The simplest workaround is to always ask for a tty frame, and let
     server.el check whether it makes sense.  */
  if (tty || !current_frame)
    {
      display = (const char *) ttyname (fileno (stdout));
      current_frame = 0;
      tty = 1;
    }
#endif

there's this bit of code (non-WINDOWSNT-specific):

  /* --no-wait implies --current-frame on ttys when there are file
     arguments or expressions given.  */
  if (nowait && tty && argc - optind > 0)
    current_frame = 1;

which causes the bug. I'm not sure I understand the logic after that
code, and even less sure it makes sense on Windows. WDYT?

    Juanma

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.