unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Stefan Monnier <monnier@iro.umontreal.ca>
To: David Reitter <david.reitter@gmail.com>
Cc: 3303@emacsbugs.donarmstrong.com,
	Adrian Robert <adrian.b.robert@gmail.com>
Subject: bug#3303: delete-frame raises old (invisible) frame
Date: Mon, 18 May 2009 22:46:19 -0400	[thread overview]
Message-ID: <jwveiul25jr.fsf-monnier+emacsbugreports@gnu.org> (raw)
In-Reply-To: <5C67F4CF-F798-4972-90DE-0489B1E10706@gmail.com> (David Reitter's message of "Mon, 18 May 2009 19:00:17 -0400")

>>> Precisely for this reason is the patch not sufficient.
>> 
>> I do not understand.
>> 
>>> When there is a hidden frame, and you delete the only other existing
>>> frame,
>>> we end up in a situation where there is no key window to receive the
>>> event,
>>> and all events (including menu items) are simply dropped.
>> 
>> Could you explain concretely why it's a problem.

> Well, if you have only hidden frames this way, you will receive no key
> events:

> (progn
>   (make-frame-invisible (selected-frame) t)
>   (make-frame)
>   (delete-frame (selected-frame) t))

> The Lisp level doesn't even see menu events.

You just repeated what you had already written.  It's not concrete
enough for me to understand.  What means "receive no key event" or "Lisp
doesn't even see menu events"?

> A little more investigation shows that we get the event in keyDown:, but we
> discard it in this code:

>  if (![[self window] isKeyWindow])
>    {
>      /* XXX: There is an occasional condition in which, when Emacs display
>          updates a different frame from the current one, and temporarily
>          selects it, then processes some interrupt-driven input
>          (dispnew.c:3878), OS will send the event to the correct NSWindow,
> but
>          for some reason that window has its first responder set to the
> NSView
>          most recently updated (I guess), which is not the correct one. */
>      if ([[theEvent window] isKindOfClass: [EmacsWindow class]])
> 	      [(EmacsView *)[[theEvent window] delegate] keyDown: theEvent];
>      return;
>    }

I think I understand: you mean that when there's only one frame and it's
invisible, we actively ignore *all* events (rather than the OS refusing
to deliver them to us), and hence Emacs becomes completely unresponsive.
Yes, that bug would need to be fixed.

> Even with this workaround/fix, now we're back to the other problem with this
> bit of code:

> (progn
>   (make-frame-invisible (selected-frame) t)
>   (make-frame)
>   (delete-frame (selected-frame) t)
>   (make-frame)
>   (sit-for 0)
>   (delete-frame (selected-frame) t))

I still don't understand the above code, for the reason already
explained: you use `selected-frame' in a way that seems to imply that
you expect make-frame to change the selected-frame, where its docstring
says explicitly that it doesn't.


        Stefan






  reply	other threads:[~2009-05-19  2:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-05-16  1:09 bug#3303: delete-frame raises old (invisible) frame David Reitter
2009-05-17 19:06 ` Stefan Monnier
2009-05-17 19:12   ` David Reitter
2009-05-17 20:43     ` Stefan Monnier
2009-05-17 22:27       ` Lennart Borgman
2009-05-18  3:26         ` Stefan Monnier
2009-05-18  1:16       ` Adrian Robert
2009-05-18  3:33         ` Stefan Monnier
2009-05-18  8:05           ` Adrian Robert
2009-05-18 15:08             ` David Reitter
2009-05-18 20:12               ` Stefan Monnier
2009-05-18 23:00                 ` David Reitter
2009-05-19  2:46                   ` Stefan Monnier [this message]
2009-05-19  2:56                     ` David Reitter
2009-05-19  3:09                       ` Stefan Monnier
2009-05-19  3:15                         ` David Reitter
2009-05-19  8:20                       ` YAMAMOTO Mitsuharu
2009-05-19 14:30                         ` Stefan Monnier
2009-05-20  2:07                       ` David Reitter
2009-05-19  0:58               ` YAMAMOTO Mitsuharu
2009-05-18  8:19           ` YAMAMOTO Mitsuharu
  -- strict thread matches above, loose matches on Subject: below --
2009-05-16 19:28 Chong Yidong
2009-05-17  2:55 ` David Reitter
2009-05-22  3:57 David Reitter
2009-05-25 15:17 ` Stefan Monnier
2009-05-26 18:20   ` David Reitter
2009-05-26 19:37     ` Stefan Monnier
2009-05-26 20:15       ` David Reitter
2009-05-26 21:30         ` Stefan Monnier
2009-05-27  4:51     ` Adrian Robert
2009-05-27 14:36       ` Stefan Monnier
2009-06-01  9:37         ` Adrian Robert
2009-05-27 15:28       ` David Reitter

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to=jwveiul25jr.fsf-monnier+emacsbugreports@gnu.org \
    --to=monnier@iro.umontreal.ca \
    --cc=3303@emacsbugs.donarmstrong.com \
    --cc=adrian.b.robert@gmail.com \
    --cc=david.reitter@gmail.com \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).