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 21:14:38 +0200 Message-ID: References: <58F23339.6090201@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492283719 22969 195.159.176.226 (15 Apr 2017 19:15:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 15 Apr 2017 19:15: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 21:15:10 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 1czTA5-0005jk-Dq for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 21:15:10 +0200 Original-Received: from localhost ([::1]:57734 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czTAB-0001nD-9Y for geb-bug-gnu-emacs@m.gmane.org; Sat, 15 Apr 2017 15:15:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57679) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1czTA4-0001i2-4Z for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 15:15:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1czT9z-0002VD-5G for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 15:15:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:51173) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1czT9y-0002Uy-SJ for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 15:15:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1czT9y-0005iL-Nf for bug-gnu-emacs@gnu.org; Sat, 15 Apr 2017 15:15: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 19:15: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.149228369021923 (code B ref 26513); Sat, 15 Apr 2017 19:15:02 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 19:14:50 +0000 Original-Received: from localhost ([127.0.0.1]:49371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czT9l-0005hX-TE for submit@debbugs.gnu.org; Sat, 15 Apr 2017 15:14:50 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:55125) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1czT9k-0005hJ-EJ for 26513@debbugs.gnu.org; Sat, 15 Apr 2017 15:14:49 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id 159A7223E6 for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 19:10:52 +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= 1492283450; x=1493147451; bh=Q1NGQWgd5jJg0VO9sxIfD8Jf0LuJPZk2kcQ Qe8CpqN0=; b=C6E0zOZHDN749ZaHgwR7/OtRYuCinZVa/NoIzmRVJJlTCOvlRy7 BuP2nvEWzgoN+HWZkfs7uy3+yjOqm4nbV1mCAJryZgUBIJyDDBVlCp6oMbDQofT9 4g66StDy9QK2d5EgZLkHOHrkgxXZX/4RAHloDM+YY8U3h4iemBi8toIE= 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 Q9_0AOp_KWCy for <26513@debbugs.gnu.org>; Sat, 15 Apr 2017 19:10: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 BE8412238D; Sat, 15 Apr 2017 19:10:49 +0000 (UTC) In-Reply-To: <58F23339.6090201@gmx.at> (martin rudalics's message of "Sat, 15 Apr 2017 16:50:33 +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:131618 Archived-At: On Sat, Apr 15 2017 at 04:50:33 pm, martin rudalics wrote: >> M-x set-variable RET pop-up-frames RET t RET >> M-x global- TAB >> >> The *Completions* buffer is opened in a new frame, but the cursor is in >> the frame too, so the user has to switch back to the minibuffer to >> continue typing. >> >> How can the user ensure that the cursor goes back to the minibuffer >> automatically? Could the solution be documented somewhere (maybe in the >> docstring of `pop-up-frames') or could the completion code take care of >> it? > > This use of *Completions* seems strange in another way: When I click on > one of the items in the *Completions* buffer or type RET on it, the > respective mode is enabled and the *Completions* frame stays around. Is > that the desired behavior? (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 can imagine that some people would instead prefer to just hide the *Completions* frame when it's not needed (by changing the frame visibility parameter). Or it could be shrunk to a small size when not needed, and then resized to fit its new contents when summoned again. There could be many different strategies. For me, the advantage of a separate *Completions* frame would be that you can place it once on your display at the start of your Emacs session, and afterwards you never incur the cost of splitting windows, creating frames or switching buffers for completions again -- and you would always know where to look for them. It could also be useful to still have the *Completions* buffer in view /after/ completion has been done -- say you hit C-x C-f TAB to see the files in the current directory, then pick one and hit RET; if the *Completions* frame sticks around, you can use it to get an idea of what other files are there. 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.