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:28:46 +0200 Message-ID: References: <58F23339.6090201@gmx.at> <58F27723.8010706@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492288159 1718 195.159.176.226 (15 Apr 2017 20:29:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Apr 2017 20:29:19 +0000 (UTC) Cc: 26513@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Apr 15 22:29:12 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 1czUJj-0000DR-LK for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 22:29:11 +0200 Original-Received: from localhost ([::1]:57995 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czUJn-0003xf-J9 for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 16:29:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40080) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czUJg-0003xO-2j for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:29:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czUJc-0000j3-VP for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:29:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51228) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1czUJc-0000iz-Lf for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:29:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1czUJc-0007RX-Fk for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 16:29:04 -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:29:04 +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.149228813728583 (code B ref 26513); Sat, 15 Apr 2017 20:29:04 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 20:28:57 +0000 Original-Received: from localhost ([127.0.0.1]:49425 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czUJV-0007Qx-Jy for submit@debbugs.gnu.org; Sat, 15 Apr 2017 16:28:57 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:55203) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czUJT-0007Ql-OD for 26513@debbugs.gnu.org; Sat, 15 Apr 2017 16:28:56 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 0EB9B223E6 for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 20:25:00 +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= 1492287898; x=1493151899; bh=cBFpbe7cc0nPL9KM+17X0U8ZhqikQ0G8GtS HiZ0hins=; b=tiCsUeeOcpbtEu4oBOQ2iEuzWW9DAtULC+iML6jhqWmjbSRcwYJ NMdlVI97xAa63CZ1ZSuDiAbD9gwsxSAAjIrZV3OySyCl6bjDgml7/LjKe5+qqzhr m7YmzWpFA/vPgYhfMqD0fR4BM3YufO86zeActUW3oe1wiAabRhSHmTGg= 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 gv7RmouU4Vi1 for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 20:24:58 +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 8033E2238D; Sat, 15 Apr 2017 20:24:56 +0000 (UTC) In-Reply-To: <58F27723.8010706@gmx.at> (martin rudalics's message of "Sat, 15 Apr 2017 21:40:19 +0200") 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:131624 Archived-At: On Sat, Apr 15 2017 at 09:40:19 pm, martin rudalics wrote: >> (The frame is iconified in this case for me.) I wouldn't mind if the >> frame just stayed where it was (i.e. no iconification), and I think this >> can be done quite easily by overriding the function >> `minibuffer-hide-completions', and possibly by dedicating the >> *Completions* buffer to the window displaying it in its own frame >> (otherwise it can happen that the frame ends up showing some other >> buffer -- not yet sure how this happens). Other ideas welcome, of >> course. > > I must admit that I never use completion after M-x. I was simply > stupefied by the fact that it immediately executed a command instead of > putting the command into the minibuffer, let me regard it and execute it > after I typed RET there. Really? But selecting a completion with the mouse or with RET in the *Completions* window with pop-up-frames set to nil does the same. Granted, though, it's probably not a very common thing to do. And also, sorry if this was not clear, but this bug is for completion everywhere in Emacs, not just M-x. >> But the main issue for now lies in focus being given to the >> *Completions* frame when completion is initiated. The equivalent with >> `pop-up-frames' equal to nil would be if the *Completions* window was >> selected after hitting TAB during completion. It's not intuitive. > > It should be now possible to do that on X and Windows by using the > 'no-focus-on-map' parameter I added this week. I'm not sure whether > such a thing exists for NS. By default, a new Window Manager window > always gets focus. Thank you; I wasn't aware of this. Now it makes sense why the *Completions* frame gets focus. One solution to this problem, then, might be to create a separate *Completions* frame on startup and update it with completions as necessary, without ever deleting/recreating it. I'll see if I can write a mode or something for this. > Taking it away from the window right after creation might be tricky, > sometimes. > > Still, why would you want to "continue typing in the minibuffer" when > the desired effect of what you do is to choose and execute one of the > commands shown in the *Completions* buffer? As explained above, it isn't necessarily the desired effect, only one example.