From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: charles@aurox.ch (Charles A. Roelli) Newsgroups: gmane.emacs.bugs Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer Date: Sat, 15 Apr 2017 22:05:39 +0200 Message-ID: References: <7e856815-6dff-4152-b144-c45a4bedb0b4@default> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492286774 16358 195.159.176.226 (15 Apr 2017 20:06:14 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Apr 2017 20:06:14 +0000 (UTC) Cc: 26513@debbugs.gnu.org To: Drew Adams Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 15 22:06:09 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 1czTxR-00049R-0h for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 22:06:09 +0200 Original-Received: from localhost ([::1]:57872 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czTxX-0008Ia-1Q for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 16:06:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36086) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czTxQ-0008IU-2W for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:06:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czTxL-0001p1-3b for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:06:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51206) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1czTxK-0001ov-Ra for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:06:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1czTxK-0006ud-EA for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: charles@aurox.ch (Charles A. Roelli) Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Apr 2017 20:06: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.149228675326556 (code B ref 26513); Sat, 15 Apr 2017 20:06:02 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 20:05:53 +0000 Original-Received: from localhost ([127.0.0.1]:49405 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czTxB-0006uG-GK for submit@debbugs.gnu.org; Sat, 15 Apr 2017 16:05:53 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:55179) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czTx9-0006u2-8w for 26513@debbugs.gnu.org; Sat, 15 Apr 2017 16:05:52 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 8BAB3223E6 for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 20:01:51 +0000 (UTC) Authentication-Results: sinyavsky.aurox.ch (amavisd-new); dkim=pass (1024-bit key) reason="pass (just generated, assumed good)" header.d=aurox.ch DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=aurox.ch; h= content-type:content-type:mime-version:message-id:in-reply-to :date:date:references:subject:subject:to:from:from; s=dkim; t= 1492286510; x=1493150511; bh=c1qgC85MV/v+/9iw4BvHcwvGHMklJNflWky /23F694Q=; b=EJbruaVBK0AgkUU9fwQGMkGWae5L5cfhokQNJV0NNqPCbECBEEl q4UdLag2ssKUEq9K4nt/iidN5dz7jaCaGbVlP1m5wH5PPllgpjPWe8U87XiHpPRO 5HMVtXOT5czH+ui1Xrcf9yEBd4sjNNl6bK4nR7T+EuO7GUPboQGoOXa8= X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com Original-Received: from sinyavsky.aurox.ch ([127.0.0.1]) by sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id seejH0lCI2WO for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 20:01:50 +0000 (UTC) Original-Received: from gray (179.133.105.92.dynamic.wline.res.cust.swisscom.ch [92.105.133.179]) by sinyavsky.aurox.ch (Postfix) with ESMTPSA id C23482238D; Sat, 15 Apr 2017 20:01:49 +0000 (UTC) In-Reply-To: <7e856815-6dff-4152-b144-c45a4bedb0b4@default> (Drew Adams's message of "Sat, 15 Apr 2017 09:49:28 -0700 (PDT)") 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:131622 Archived-At: On Sat, Apr 15 2017 at 09:49:28 am, Drew Adams wrote: > FWIW, I reported such problems a couple of decades ago. > Unfortunately (for me at least), there is not enough > use or interest in using separate frames by default, > including for *Completions*, so this kind of thing has > not gotten the love it would really need for progress. Maybe it's time for some change? :-) Especially in light of the boatload of new frame stuff that was added recently (thanks to Martin for that). > I've tried to do what I can in my own environment to > handle this, especially in the context of a standalone > minibuffer frame. And Martin has been helpful wrt > problems that resulted from changes in the Emacs code > over the years. > > Here's what I do for *Completions*, FWIW: > > I add an entry to `special-display-buffer-names* that > has a function, `1on1-display-*Completions*-frame', > which takes care of displaying the *Completions* frame. > > The main thing that function does is redirect the > focus of the *Completions* frame to the standalone > minibuffer frame (if the minibuffer is active) or > (if not) to the buffer that was current before > *Completions* display was requested: > > (let ((redirect > (if (active-minibuffer-window) > 1on1-minibuffer-frame > (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)))))) > (when redirect > (redirect-frame-focus (selected-frame) > redirect))) 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. 2) I don't understand why vanilla Emacs puts the *Completions* buffer in focus when it's popped into a new frame -- but I know that this is the reason you have to redirect the focus from *Completions* to the minibuffer or the completion-reference-buffer frame. On Mac OS, though, redirecting frame focus results in a lot of flicker and lag on each keypress -- sometimes up to a second or two long. (Will save the rest for another bug report someday.) Wouldn't a simpler alternative to frame redirection be to just put point back in the minibuffer or completion-reference-buffer? > I've said it before, but I think it is relevant: > Back in the early 1990s the Emacs implementation > named `Epoch' worked very well with a standalone > minibuffer frame, out of the box. > > All I've done is try to work around Emacs's poor > (non-existent) support for this kind of use case - > essentially trying to emulate Epoch behavior. Standalone minibuffer frames are meant to work correctly almost out of the box, though, right? (IIRC you just have to fiddle with `initial-frame-alist' to remove the minibuffer from the first frame). It's only when *Completions* is displayed in a separate frame that there are issues. > 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. Yes, this seems like it's the main issue here. But still, sane frame behavior doesn't seem too far off.