bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#17975: 24.3.92; assertion failure deleting frames with varying names


From: Ken Raeburn
Subject: bug#17975: 24.3.92; assertion failure deleting frames with varying names for the same display (and, using multiple X11 connections in that case too)
Date: Fri, 11 Jul 2014 17:22:17 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.92 (gnu/linux)

Dmitry Antipov <address@hidden> writes:
> Reproduced. The whole thing looks like a mystery (perhaps Xlib makes a
> difference between :0 and :0.0 somewhere in its innards), but this
> workaround works for me. Can you please try it too?

It works for me too. Of course, my saved .emacs.desktop already has a
mix of display names in it; I'll have to get them in sync.

But of course it isn't going to address some reasonable uses of
make-frame-on-display (including perhaps old scripts some of us may have
lying around that invoke make-frame-on-display by way of emacsclient
--eval). Perhaps a similar change can be made within the main Emacs
code?

I can reformulate the recipe in a form without emacsclient, for testing
purposes:

 $ DISPLAY=:0 emacs -Q --eval \
 '(let ((f (selected-frame))) (make-frame-on-display ":0.0") (delete-frame f))'

If I use "(make-frame)" instead, or give make-frame-on-display the
initial DISPLAY value, it works fine.

It appears that mixing ":0" and "unix:0" can trigger the problem, too.
At least in my X11 environment, ":0" or ":0.0" seem to be the preferred
forms. So launching a non-daemon Emacs from xterm and then using the
modified emacsclient with it could also be a problem, but I haven't
tested it yet.

Ken





reply via email to

[Prev in Thread] Current Thread [Next in Thread]