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: Mon, 17 Apr 2017 09:44:03 +0200 Message-ID: References: <58F23339.6090201@gmx.at> <58F27723.8010706@gmx.at> <58F31A4F.9010002@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1492415115 31469 195.159.176.226 (17 Apr 2017 07:45:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 17 Apr 2017 07:45:15 +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 Mon Apr 17 09:45:07 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 1d01LP-0007ze-AH for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Apr 2017 09:45:07 +0200 Original-Received: from localhost ([::1]:35263 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d01LU-0007Uy-VO for geb-bug-gnu-emacs@m.gmane.org; Mon, 17 Apr 2017 03:45:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:36527) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d01LP-0007TK-Fe for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2017 03:45:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d01LK-00071L-IT for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2017 03:45:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53194) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d01LK-00070t-8z for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2017 03:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d01LK-0003Z6-0M for bug-gnu-emacs@gnu.org; Mon, 17 Apr 2017 03:45: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: Mon, 17 Apr 2017 07:45:01 +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.149241505813632 (code B ref 26513); Mon, 17 Apr 2017 07:45:01 +0000 Original-Received: (at 26513) by debbugs.gnu.org; 17 Apr 2017 07:44:18 +0000 Original-Received: from localhost ([127.0.0.1]:51392 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d01Kb-0003Xo-Qn for submit@debbugs.gnu.org; Mon, 17 Apr 2017 03:44:18 -0400 Original-Received: from sinyavsky.aurox.ch ([37.35.109.145]:56163) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d01Ka-0003XY-4k for 26513@debbugs.gnu.org; Mon, 17 Apr 2017 03:44:16 -0400 Original-Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1]) by sinyavsky.aurox.ch (Postfix) with ESMTP id A33F8223F0 for <26513@debbugs.gnu.org>; Mon, 17 Apr 2017 07:40:16 +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= 1492414814; x=1493278815; bh=4nTo06dWyaP1vAJ+HE0AddX/Vym0UNxx0Z6 NRoozfzc=; b=Sbtb+Mui/282IFiBUnuwxnvGoWjbohBrF2+0vasvIUoYlsABVQ9 rrjJxqjfyhQuSbz2huQyQ/LhIrLoJZ0T/O6Oe8TczCj5IQMcT4hPJhhNxgOZ/zH8 lv+Bo5CifyB6BFFt0taWWPrmvunS3B1DAZWjIkSVawdNdHP/jwoiujvA= 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 T9dw7ocpY_Kk for <26513@debbugs.gnu.org>; Mon, 17 Apr 2017 07:40:14 +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 9B9A2223DB; Mon, 17 Apr 2017 07:40:12 +0000 (UTC) In-Reply-To: <58F31A4F.9010002@gmx.at> (martin rudalics's message of "Sun, 16 Apr 2017 09:16:31 +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:131678 Archived-At: >> 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. > > Yes. But I never noticed. I could have sworn that I had to type RET > somewhere to confirm that I really wanted to do what I picked with the > mouse or via RET in the *Completions* buffer before. Have you ever tried Drew's icicles library before? If you load it from emacs -Q and enable it with M-x icicle-mode, and type M-x global- TAB as before, then hitting TAB "cycles" to the next completion in the *Completions* buffer. Cycling in this case means two things: a) Replacing the current minibuffer input with the completion cycled to, and highlighting it as the active region in the minibuffer b) Moving point in the *Completions* window to the selected completion and highlighting it with a special face there as well. But the *Completions* window is never (to my knowledge) the selected window for the user. This would be a good model to follow (IMO): the user can initiate completion with TAB, using it to complete, say, an initial prefix, and then hit TAB a few more times to cycle to a chosen candidate, all without ever leaving the minibuffer window. >> 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. > > That's why I asked. I now think that for most users the behavior that > the frame is selected is quite normal (for M-x) and I rather would > expect the *Completions* window to be selected too when it appears on > the same frame. The current behavior is inconsistent. See above for a way to allow cycling candidates with TAB without the *Completions* window having to be selected. In other applications (say, the bash shell), hitting TAB to complete something never prevents you from continuing to type (as would happen in Emacs if the *Completions* window were always selected when you initiate completion). >> 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. > > Even then it might get focus. With a focus follows mouse policy, raising > a frame that happens to be under the mouse pointer will usually also > focus it (blame the window manager for that). True, I will have to try it out and see if that's a problem. >>> 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. > > Maybe it would then make sense to discriminate the use cases of > *Completions*: One where continuing typing in the selected window > wouldn't make sense because one has to select an item in the > *Completions* buffer. In that case selecting the *Completions* window > makes perfect sense IMHO. And one where you usually want to continue > typing and the *Completions* buffer is just there for later perusal. Again, see above for Drew's approach, since it allows both use cases easily.