bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[Tobias Bading]

Boys & girls, please *do* try this at home! (Or whereever your Emacs is :-). Works with r108017 of the emacs-24 branch on GNU/Linux as well as Mac OS for me.)

emacs -Q:
C-h v TAB C-x o C-x 0

Your Emacs frame should now contain a single window with a completion list of variables.
Take your pick: Select any variable either with your mouse, trackpad or keyboard.... Oooops! :-D

Have fun,
Tobias

PS: New package hide-and-seek.el maybe? ;-)

---

In GNU Emacs 24.0.97.1 (x86_64-apple-darwin10.8.0, NS apple-appkit-1038.36)
of 2012-05-27 on Gecko.local
Windowing system distributor `Apple', version 10.3.1038
Configured using:
`configure '--with-ns''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: de_DE.UTF-8
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

Major mode: Lisp Interaction

Minor modes in effect:
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
C-h v <tab> C-x o C-x 0 <down> <down> <down> <down> 
<down> <return> <menu-bar> <help-menu> <send-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Type C-x 1 to delete the help window.

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail regexp-opt rfc2047 rfc2045 ietf-drums
mm-util mail-prsvr mail-utils help-mode easymenu view help-fns time-date
tooltip ediff-hook vc-hooks lisp-float-type mwheel ns-win tool-bar dnd
fontset image fringe lisp-mode register page menu-bar rfn-eshadow timer
select scroll-bar mouse jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev minibuffer loaddefs button faces cus-face files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process ns
multi-tty emacs)

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[Troels Nielsen]

On Sun, May 27, 2012 at 4:59 PM, Tobias Bading <tbading@web.de> wrote:
> Boys & girls, please *do* try this at home! (Or whereever your Emacs is :-). Works with r108017 of the emacs-24 branch on GNU/Linux as well as Mac OS for me.)
>
> emacs -Q:
> C-h v TAB C-x o C-x 0
>
> Your Emacs frame should now contain a single window with a completion list of variables.
> Take your pick: Select any variable either with your mouse, trackpad or keyboard.... Oooops! :-D

Well, it looks as though the *Completions* buffer only wants to be a
little thorough when hiding itself.

I don't really know the origin of the behavior, but I think it's
natural if there had been opened a special frame just for the
*Completions* buffer, so I suppose that's why it has been put there.

I propose the following patch, which does a little more checking if
it's likely that emacs has been opening a special frame for the
*Completions*-buffer. With some effort you could probably still get
emacs to iconify an unexpecting frame, but I don't think many people
would, if not for playing hide and seek that is... ;)

Regards
Troels

=== modified file 'lisp/ChangeLog'
--- lisp/ChangeLog	2012-05-27 01:06:44 +0000
+++ lisp/ChangeLog	2012-05-27 22:18:53 +0000
@@ -1,3 +1,8 @@
+2012-05-27  Troels Nielsen <bn.troels@gmail.com>
+
+	* simple.el (choose-completion): Be a little more particular
+	before iconifying a frame, when a completion has been chosen.
+
 2012-05-27  Eli Zaretskii  <eliz@gnu.org>

 	* mail/sendmail.el (mail-yank-region): Recognize

=== modified file 'lisp/simple.el'
--- lisp/simple.el	2012-05-04 23:16:47 +0000
+++ lisp/simple.el	2012-05-27 22:15:15 +0000
@@ -6214,7 +6215,11 @@
         (error "Destination buffer is dead"))
       (select-window (posn-window (event-start event)))
       (if (and (one-window-p t 'selected-frame)
-	       (window-dedicated-p (selected-window)))
+               (window-dedicated-p (selected-window))
+               (let ((buffer-name (buffer-name
+                                   (window-buffer (selected-window)))))
+                 (and (not (same-window-p buffer-name))
+                      (special-display-p buffer-name))))
 	  ;; This is a special buffer's frame
 	  (iconify-frame (selected-frame))
 	(or (window-dedicated-p (selected-window))

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[martin rudalics]

 > I propose the following patch, which does a little more checking if
 > it's likely that emacs has been opening a special frame for the
 > *Completions*-buffer. With some effort you could probably still get
 > emacs to iconify an unexpecting frame, but I don't think many people
 > would, if not for playing hide and seek that is... ;)

Why can't we use `window--delete' instead of `iconify-frame' here?

martin

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[Stefan Monnier]

>> I propose the following patch, which does a little more checking if
>> it's likely that emacs has been opening a special frame for the
>> *Completions*-buffer. With some effort you could probably still get
>> emacs to iconify an unexpecting frame, but I don't think many people
>> would, if not for playing hide and seek that is... ;)

Checking special-display-p is not a good idea.
OTOH, it'd be OK to check whether the frame has an active minibuffer
(IOW make sure we don't iconify an active minibuffer), and/or make sure
the frame is not the last one.

> Why can't we use `window--delete' instead of `iconify-frame' here?

Probably no reason.


        Stefan

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[martin rudalics]

[-- Attachment #1: Type: text/plain, Size: 266 bytes --]

 >> Why can't we use `window--delete' instead of `iconify-frame' here?
 >
 > Probably no reason.

Then maybe we should use `quit-window' in the first place.  Attached
find a patch for those who would give it a try (I hardly ever see the
completions buffer).

martin

[-- Attachment #2: simple.diff --]
[-- Type: text/plain, Size: 929 bytes --]

*** lisp/simple.el	2012-05-04 23:16:47 +0000
--- lisp/simple.el	2012-05-28 17:54:25 +0000
***************
*** 6212,6227 ****
  
        (unless (buffer-live-p buffer)
          (error "Destination buffer is dead"))
!       (select-window (posn-window (event-start event)))
!       (if (and (one-window-p t 'selected-frame)
! 	       (window-dedicated-p (selected-window)))
! 	  ;; This is a special buffer's frame
! 	  (iconify-frame (selected-frame))
! 	(or (window-dedicated-p (selected-window))
! 	    (bury-buffer)))
!       (select-window
!        (or (get-buffer-window buffer 0)
!            owindow))
  
        (with-current-buffer buffer
          (choose-completion-string
--- 6212,6218 ----
  
        (unless (buffer-live-p buffer)
          (error "Destination buffer is dead"))
!       (quit-window nil (posn-window (event-start event)))
  
        (with-current-buffer buffer
          (choose-completion-string

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[Troels Nielsen]

> Then maybe we should use `quit-window' in the first place.  Attached
> find a patch for those who would give it a try (I hardly ever see the
> completions buffer).

Yes, it works nicely, as far as I can see when there is only one
frame. When anymore, the problem occurs just as before.

I suppose Stefan earlier hinted at something like this patch, which
together with your earlier simplification sort of fixes the problem.

Regards
Troels

=== modified file 'lisp/window.el'
--- lisp/window.el	2012-05-04 23:16:47 +0000
+++ lisp/window.el	2012-05-28 22:35:25 +0000
@@ -2371,7 +2371,10 @@ (defun window-deletable-p (&optional win
      ((frame-root-window-p window)
       ;; WINDOW's frame can be deleted only if there are other frames
       ;; on the same terminal.
-      (unless (eq frame (next-frame frame 0))
+      (unless (or (eq frame (next-frame frame 0))
+                  ;; Don't delete frame if its minibuffer is active.
+                  (let ((minibuf (active-minibuffer-window)))
+                    (and minibuf (eq frame (window-frame minibuf)))))
 	'frame))
      ((or ignore-window-parameters
 	  (not (eq (window-parameter window 'window-side) 'none))

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[martin rudalics]

 > I suppose Stefan earlier hinted at something like this patch, which
 > together with your earlier simplification sort of fixes the problem.

I see.  Even if doesn't fix each and every problem in this area, we
should install it (or something similar).

martin

bug#11567: 24.0.97; WTF? ROFL! (hilarious bug)

[Chong Yidong]

martin rudalics <rudalics@gmx.at> writes:

>> I suppose Stefan earlier hinted at something like this patch, which
>> together with your earlier simplification sort of fixes the problem.
>
> I see.  Even if doesn't fix each and every problem in this area, we
> should install it (or something similar).

OK, I have committed your patch and Torels' to the trunk.

Emacs 23.4 has the exact same behavior, so it's not a regression, and
the problem isn't important enough to fix for 24.1.