From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer Date: Sun, 16 Apr 2017 08:54:37 -0700 (PDT) Message-ID: References: <7e856815-6dff-4152-b144-c45a4bedb0b4@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1492358119 6257 195.159.176.226 (16 Apr 2017 15:55:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 16 Apr 2017 15:55:19 +0000 (UTC) Cc: 26513@debbugs.gnu.org To: charles@aurox.ch Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 16 17:55:11 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czmW6-0001My-Ve for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Apr 2017 17:55:11 +0200 Original-Received: from localhost ([::1]:60967 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czmWC-0001nm-Hm for geb-bug-gnu-emacs@m.gmane.org; Sun, 16 Apr 2017 11:55:16 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:53780) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czmW1-0001lU-N1 for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 11:55:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czmVy-0002SR-KI for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 11:55:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:52684) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1czmVy-0002SJ-Gw for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 11:55:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1czmVy-00088h-8H for bug-gnu-emacs@gnu.org; Sun, 16 Apr 2017 11:55:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Apr 2017 15:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26513 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26513-submit@debbugs.gnu.org id=B26513.149235809531271 (code B ref 26513); Sun, 16 Apr 2017 15:55:02 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 16 Apr 2017 15:54:55 +0000 Original-Received: from localhost ([127.0.0.1]:50883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czmVq-00088I-Np for submit@debbugs.gnu.org; Sun, 16 Apr 2017 11:54:54 -0400 Original-Received: from userp1040.oracle.com ([156.151.31.81]:38381) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czmVp-000886-2B for 26513@debbugs.gnu.org; Sun, 16 Apr 2017 11:54:53 -0400 Original-Received: from userv0022.oracle.com (userv0022.oracle.com [156.151.31.74]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id v3GFshZC003955 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 16 Apr 2017 15:54:44 GMT Original-Received: from userv0122.oracle.com (userv0122.oracle.com [156.151.31.75]) by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3GFshj0015636 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 16 Apr 2017 15:54:43 GMT Original-Received: from abhmp0016.oracle.com (abhmp0016.oracle.com [141.146.116.22]) by userv0122.oracle.com (8.14.4/8.14.4) with ESMTP id v3GFseaw026352; Sun, 16 Apr 2017 15:54:40 GMT In-Reply-To: X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 12.0.6767.5000 (x86)] X-Source-IP: userv0022.oracle.com [156.151.31.74] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.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" Xref: news.gmane.org gmane.emacs.bugs:131652 Archived-At: > 1) Does this still work without a standalone minibuffer frame? I'm > interested in using one, but I'd rather fix the *Completions* frame > problem first before adding on a minibuffer-only frame to my setup. I can make it work without a standalone minibuffer frame in all Emacs versions before Emacs 25. For some reason, redirecting the frame focus does not seem to work right for Emacs 25 when there is no standalone minibuffer frame. I hope I'm just missing something simple. The following code works, for example, except for Emacs 25. (I have Emacs 25.1-2.) Maybe you or Martin can explain why. The debug `message' calls here don't tell me that anything is wrong, but clearly something is. I tried some variants also (no `w32-grab-focus-on-raise', explicitly select *Completions* frame (and even set focus to it temporarily), etc., to no avail. (defun foo () (interactive) (add-to-list 'special-display-buffer-names `("*Completions*" display-comp-fr)) (setq w32-grab-focus-on-raise nil)) (defun display-comp-fr (buf &optional args) (let ((return-window (select-window (funcall special-display-function buf args)))) (raise-frame) (message "BUF: %S, WIN: %S, FR: %S" buf (get-buffer-window buf) (window-frame (get-buffer-window buf))) (let* ((mini-win (active-minibuffer-window)) (redirect (if mini-win (window-frame mini-win) (and completion-reference-buffer (get-buffer-window completion-reference-buffer 'visible) (not (eq (get-buffer "*Completions*") completion-reference-buffer)) (window-frame (get-buffer-window completion-reference-buffer t)))))) (message "M: %S, REFB: %S, RFR: %S, SELFR: %S" ; @@@ mini-win completion-reference-buffer redirect (selected-frame)) (redirect-frame-focus (selected-frame) redirect)) return-window)) > 2) I don't understand why vanilla Emacs puts the *Completions* > buffer in focus when it's popped into a new frame Martin answered this question, I think. The window mgr does this, depending on your window mgr. Once the frame exists, it does not do it. But MS Windows, for example, gives the focus to a new frame that is displayed. > Standalone minibuffer frames are meant to work correctly > almost out of the box, though, right? They should be meant to do that, yes, IMO. > > But frames remain the poor cousin to windows in > > Emacs. Part of that is likely due to the fact that > > Emacs cannot completely control the behavior of > > frames for all window managers. Window mgrs are > > different, and they have ultimate control. >=20 > Yes, this seems like it's the main issue here. But=20 >still, sane frame behavior doesn't seem too far off. Hope springs eternal. ;-)