GNU bug report logs - #26513
25.2; pop-up-frames and *Completions* buffer

Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.

Package: emacs; Reported by: charles@HIDDEN (Charles A. Roelli); dated Sat, 15 Apr 2017 09:18:01 UTC; Maintainer for emacs is bug-gnu-emacs@HIDDEN.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 19 Apr 2017 07:27:28 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Wed Apr 19 03:27:28 2017
Received: from localhost ([127.0.0.1]:55445 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1d0k1O-00048C-PM
	for submit <at> debbugs.gnu.org; Wed, 19 Apr 2017 03:27:28 -0400
Received: from mout.gmx.net ([212.227.17.22]:60806)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1d0k1M-00047z-Tt
 for 26513 <at> debbugs.gnu.org; Wed, 19 Apr 2017 03:27:25 -0400
Received: from [192.168.1.100] ([213.162.68.69]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Man6U-1cks5Y3rMw-00KQpz; Wed, 19
 Apr 2017 09:27:07 +0200
Message-ID: <58F71140.60500@HIDDEN>
Date: Wed, 19 Apr 2017 09:26:56 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: "Charles A. Roelli" <charles@HIDDEN>, Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>	<7e856815-6dff-4152-b144-c45a4bedb0b4@default>	<m2efwttp0s.fsf@HIDDEN>	<ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default>
 <m2efwpmp4d.fsf@HIDDEN>
In-Reply-To: <m2efwpmp4d.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:R9HEdvWPgiWCcMavMi8p+OAiagALIB30oq1FQ1/ZL/efig2Jnch
 ZmwHQlUalVJNz7/NMHwdWj8to/0s+sD9v1OwJAIW2DKz9fYqGVUCxKL5JHENZIdLzuBS5ns
 vWHN6fE8ZW10IrZtBw6Li2pOTqHtcIkA/OqmWuM5+IsE7Jgjd12rG498oX3O8ZfDtVy+wqN
 dzr+HUY0ATojqvx5hIMUg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:aq+eA8TjasE=:z0xFPaIaPs8X1Ngutjuzb2
 29RRSQc56iQvBmXocNi8Azb7HYt5Sit6DInA+9xDWnUDjow2UWZUMCIx/A5NEbk98ZprPXObw
 FLLLBk7efOhIIiU9UPecZhZdmPFa98zZAGyB7o3WZBVCLgGqFsi/1t02bm7gHIqNwDvtc3xZo
 V53qWL0wb26eljZhFA0o0G2myW42tnFYt68fLfPFLqMlTF5QsOKVw2EeRkPi6KJTriE7jntJq
 JdJQVn2HK1fS9Dv0ZWXNzeFF6PjFnT8MOh0B92BE6U41EyXYhRaAy9KZR51dQ1Gh+ahFJW4JN
 EA7SQYcmvAJ382dxtTxnPO8p24gfo29nvxe8OUcio3YJL8LNuwqBPEqLyxSlgwOFzUL4FArm5
 41MolKr31HyEk2Jda819XT6AJPVDK5dEgmlzUAsu89mSwdEywja6worWOArdDyop5aMJT55Pe
 hH66PObH6I0YKzIYdf+JoU+9a5pSB9aKF9HPM8KQl2TXqibMgfnu+mKHNdP9E2Y2deZUuFbOq
 RAXXpMQBdGyI8cfL4StrYT2soICPrK0+JYE1ygNjo9blGvUloGeFX2f/3tyszCoISx9/0X1pP
 EajATTjlu38/Np+QH17CF+aa2gbta30Wo89FO4cSiX22JMugpeaY3kNV2tTubvJJKzmKi/KNU
 BVWjT9jksRBgXMtE/nTNXSovhzNvViDxPuJ3S05bcPiaLCuLMDLwpDpmRkEjzBwLjAmMYGRxA
 evwVl3oPfq98HFP4+0SJpcKdoiJKXDtVaxoURQhh8hZ8STeNK7fFmZYy4o/qQw28NqYRqrkuf
 nYXZGpHP6Mq8SW7V4FduZ7tGC3PGQ==
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

 > I also tried Martin's suggestion of removing the
 > (select-window) call but that didn't get rid of the error for me.

Evaluating with emacs -Q

(add-to-list 'special-display-buffer-names '("*Completions*" foo))
(setq w32-grab-focus-on-raise  nil)

(defun foo (buffer &optional args)
   (interactive)
   (let* ((mini-win  (active-minibuffer-window))
	 (mini-frame (window-frame mini-win))
	 (window
	  (select-window
	   (funcall special-display-function buffer args)))
	 (frame (window-frame window)))
     (raise-frame frame)
     (redirect-frame-focus frame mini-frame)
     window))

and typing

C-h f set- TAB

gets me a new frame with input focus.  Evaluating with emacs -Q

(add-to-list 'special-display-buffer-names '("*Completions*" foo))
(setq w32-grab-focus-on-raise  nil)

(defun foo (buffer &optional args)
   (interactive)
   (let* ((mini-win  (active-minibuffer-window))
	 (mini-frame (window-frame mini-win))
	 (window
	  (funcall special-display-function buffer args))
	 (frame (window-frame window)))
     (raise-frame frame)
     (redirect-frame-focus frame mini-frame)
     window))

and typing

C-h f set- TAB

gets me a new frame with input focus in the old frame.

Verified with Emacs 25 and 26 under Debian GTK+ and Windows XP.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 18 Apr 2017 20:34:40 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 18 16:34:40 2017
Received: from localhost ([127.0.0.1]:55245 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1d0Zpg-00021L-9D
	for submit <at> debbugs.gnu.org; Tue, 18 Apr 2017 16:34:40 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:57670)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1d0Zpe-000217-5s
 for 26513 <at> debbugs.gnu.org; Tue, 18 Apr 2017 16:34:38 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id DAD70223EE
 for <26513 <at> debbugs.gnu.org>; Tue, 18 Apr 2017 20:30:35 +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=
 1492547434; x=1493411435; bh=bc0brk2kZD/2U5nDwDtY2BVcX0wFkBcLxHI
 Mv3kUJTA=; b=tx4rsl1VosuHI/d/EEId5zCx3oVX2mBj5Z4TQBEuB3DhLDr9EOG
 YVRfaaaqkkCgc86B2msDVndK4mxVboM9X0OrMw8gJ4Wd8dTGhXhHQtO6KytfFPpM
 g2i27zDrAjdA1OvHhNof6MGTLcGf+EEi3tRexEiF2U89Hu7xAr6Ens7E=
X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com
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 Rmt85MyI6pdq for <26513 <at> debbugs.gnu.org>;
 Tue, 18 Apr 2017 20:30:34 +0000 (UTC)
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 B49DC223EC;
 Tue, 18 Apr 2017 20:30:33 +0000 (UTC)
From: charles@HIDDEN (Charles A. Roelli)
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
 <7e856815-6dff-4152-b144-c45a4bedb0b4@default>
 <m2efwttp0s.fsf@HIDDEN>
 <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default>
Date: Tue, 18 Apr 2017 22:34:26 +0200
In-Reply-To: <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default> (Drew Adams's
 message of "Sun, 16 Apr 2017 08:54:37 -0700 (PDT)")
Message-ID: <m2efwpmp4d.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 26513
Cc: rudalics@HIDDEN, 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

Hi Drew,

On Sun, Apr 16 2017 at 08:54:37 am, Drew Adams wrote:

>> 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))

Thanks for this minimal example.

It also doesn't work for me on Emacs 25 either.  Emacs 24.4 does work
fine, however.  I have no clue why... maybe redirect-frame-focus has
changed in Emacs 25?

Here is the recipe I used to check if it worked:

    emacs -Q
    load your two functions
    M-x foo
    M-x global- TAB auto

Typing "auto" resulted in a "Buffer is read-only: #<buffer
*Completions*>" error when the redirection wasn't working.  When the
redirection did work, the "auto" keyboard input was correctly sent to
the minibuffer.  I also tried Martin's suggestion of removing the
(select-window) call but that didn't get rid of the error for me.

>> 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.

Yep, seems to be the case for most window managers.  I never noticed
this before.

>> > 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.
>
> Hope springs eternal. ;-)

And that's what Emacs is built on. :D




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 18 Apr 2017 17:27:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Tue Apr 18 13:27:39 2017
Received: from localhost ([127.0.0.1]:55026 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1d0Wug-0004CC-T2
	for submit <at> debbugs.gnu.org; Tue, 18 Apr 2017 13:27:39 -0400
Received: from mout.gmx.net ([212.227.15.18]:49923)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1d0Wuf-0004Bi-0p
 for 26513 <at> debbugs.gnu.org; Tue, 18 Apr 2017 13:27:37 -0400
Received: from [192.168.1.100] ([213.162.68.91]) by mail.gmx.com (mrgmx002
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0MD9NE-1coT8r3vpM-00GWvP; Tue, 18
 Apr 2017 19:27:18 +0200
Message-ID: <58F64C6C.40909@HIDDEN>
Date: Tue, 18 Apr 2017 19:27:08 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: Drew Adams <drew.adams@HIDDEN>, charles@HIDDEN
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>	<7e856815-6dff-4152-b144-c45a4bedb0b4@default>	<m2efwttp0s.fsf@HIDDEN>
 <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default>
In-Reply-To: <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable
X-Provags-ID: V03:K0:C0URnj8DKEOl7UqpVONAzHGE+73cyozAvUzl3+9XGhaZSL555zP
 ZvpxEqabjSLCb1pLGXCjqHn0L9/jkiJ0nwiH2dNKS96PjN7IpeGEaeyRbnulcmw83vN/afS
 fRbKRS/Uk5925HWAknvxaN6lZlypSAIfGOz0t9N/aLlhDgnuL8m3qOsCk1dt4Z+R4zhkDzv
 9eZ6J80iFHGIAKkGxt+lA==
X-UI-Out-Filterresults: notjunk:1;V01:K0:tVefuuYYsKg=:ASv2uFXc2gufEeNReNcjzW
 StyqXfV1FsYfV0lAmzB+VU9apAtDGiwAX0SCvYA5QC8VN4P5ht4FxkJh1s8s6aoO6fuBvvo/1
 GYCWRrGncRLtSittfk6qSd1UueM5QZmWRc5QXAEAf76zEShR9MaAqRFkDxwnFTqe9G1aow0aS
 UXSIU1DlwOt0zK9af8sOq8xzEGgSGBvYLP3E2YYTB1JdbpOYS064x2DAJMkI76FEL2iTVY/fQ
 CRsnAGiFpA6De4SfVqUyBSd3ZJF8QrCY6V29GyYOOdNA1Ls8dfLVjpCEQx4p5EAdz3Q12lGaL
 pt9nlyKHzr4E4PsLsqQetwLiy/Mg2R5d3ZCepAe7Sj0u2mjF9lUMS7GmJBd9Aqrk8JTb5ENlX
 +UdM2Qgs7yyTWCUTr2Frx3TGxZHLd81gXGPHiBq6m0XZiuYS8EQ84qLpdQsrh2U8bAXl6CUr7
 d9CajnhdA+AmJsJGecE1SY2rIQGzmLgDBtvp4aDeor6hvAlF8DQ0T/AkXUziidAj6prh2w/cC
 Gbzrf6k66nZdJvRxeS3ybj6QNaUoVJQW4BH/Cr6GqE75Qa7Yn+cgeoUOZQrcvb2wts3gP3zMO
 mtqyFd+1pBFwlGfDEsQ84/HOq5J0X8aXjrci1IcsUufSIfPtT91vlqMDjwDQ07uXFeIPmVRXH
 YtsgsqRP0q1RpxCqKW6iaAoLQpyzUbCcS7q6V+72nkwkLH3zHu/BiWBWzBIhFKeICCY1KG14c
 5eWPOJtQEIvs3WLq8fvuuwrDancjqqn89SbE5WS3ubYhMSLkTADR5wU4a6NXYsOwHhjCfCT+I
 WKUoLPsD8ph+kwKfaABpv2tAr/OzA==
X-Spam-Score: -1.5 (-)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

 >    (let ((return-window
 >           (select-window
 >            (funcall special-display-function buf args))))

Remove that =E2=80=98select-window=E2=80=99 call and Bob's your uncle.

martin





Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 17 Apr 2017 07:44:18 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Mon Apr 17 03:44:18 2017
Received: from localhost ([127.0.0.1]:51392 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1d01Kb-0003Xo-Qn
	for submit <at> debbugs.gnu.org; Mon, 17 Apr 2017 03:44:18 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:56163)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1d01Ka-0003XY-4k
 for 26513 <at> debbugs.gnu.org; Mon, 17 Apr 2017 03:44:16 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id A33F8223F0
 for <26513 <at> 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
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 <at> debbugs.gnu.org>;
 Mon, 17 Apr 2017 07:40:14 +0000 (UTC)
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)
From: charles@HIDDEN (Charles A. Roelli)
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN> <58F23339.6090201@HIDDEN>
 <m2inm5trdt.fsf@HIDDEN> <58F27723.8010706@HIDDEN>
 <m24lxptny9.fsf@HIDDEN> <58F31A4F.9010002@HIDDEN>
Date: Mon, 17 Apr 2017 09:44:03 +0200
In-Reply-To: <58F31A4F.9010002@HIDDEN> (martin rudalics's message of "Sun, 16
 Apr 2017 09:16:31 +0200")
Message-ID: <m2inm3fph8.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

>> 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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 16 Apr 2017 15:54:55 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 16 11:54:55 2017
Received: from localhost ([127.0.0.1]:50883 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czmVq-00088I-Np
	for submit <at> debbugs.gnu.org; Sun, 16 Apr 2017 11:54:54 -0400
Received: from userp1040.oracle.com ([156.151.31.81]:38381)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1czmVp-000886-2B
 for 26513 <at> debbugs.gnu.org; Sun, 16 Apr 2017 11:54:53 -0400
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
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
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
MIME-Version: 1.0
Message-ID: <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default>
Date: Sun, 16 Apr 2017 08:54:37 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: charles@HIDDEN
Subject: RE: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
 <7e856815-6dff-4152-b144-c45a4bedb0b4@default> <m2efwttp0s.fsf@HIDDEN>
In-Reply-To: <m2efwttp0s.fsf@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 12.0.6767.5000 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Source-IP: userv0022.oracle.com [156.151.31.74]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

> 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. ;-)




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 16 Apr 2017 07:16:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sun Apr 16 03:16:50 2017
Received: from localhost ([127.0.0.1]:49695 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czeQU-0007Zm-Iu
	for submit <at> debbugs.gnu.org; Sun, 16 Apr 2017 03:16:50 -0400
Received: from mout.gmx.net ([212.227.17.20]:50699)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1czeQS-0007ZY-67
 for 26513 <at> debbugs.gnu.org; Sun, 16 Apr 2017 03:16:48 -0400
Received: from [192.168.1.100] ([213.162.68.14]) by mail.gmx.com (mrgmx102
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lr46Z-1cLLel3oep-00eYqG; Sun, 16
 Apr 2017 09:16:41 +0200
Message-ID: <58F31A4F.9010002@HIDDEN>
Date: Sun, 16 Apr 2017 09:16:31 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: "Charles A. Roelli" <charles@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
 <58F23339.6090201@HIDDEN>	<m2inm5trdt.fsf@HIDDEN> <58F27723.8010706@HIDDEN>
 <m24lxptny9.fsf@HIDDEN>
In-Reply-To: <m24lxptny9.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:+Q4A70c0ph7MyWqWJqfmvdbbW/Tcs159oyv3qBkh+GX6tXtNH/0
 78wTseRRlFhJt1hrS6nCOLfDmhTDyZa6ZAcHh8bCpZX48H0zAYlunaCAXOPxsSfHOF6Am+P
 bgPfbkdEuH2Nr1w6xN9xDExR63fhM4Iiw2sVNSm0luB5TcX3YnnYG32x5tRrHs45dBWIzml
 qefA4itpjTsFG6skfsNeg==
X-UI-Out-Filterresults: notjunk:1;V01:K0:rbrrEOerLOw=:UtUluDGgHqbgLZGp6vvmA0
 JigISElloIFm1kMapl1/4R7x2/JklEliYAJCndmuGUy3RjUK0E7EBptMW7jCfv4FtB20AWFtl
 T2FFgXGj2psinE3fjwKpzViuacgw8IsYHSnY4vhk5j2xklTqWbbuZDX7WZdh20x7VT+x6+Nhw
 AscmBgMmSV4FkgXo4jq0++UMgQIg6vHbMTK7wIyn0hMOlMdfK5rtGWuavC58Sb9t2dapy+tPJ
 RP+EWXydlegImTDF7mqhd/MYhpdqJkNTgPc24I5AEMU1VHRU96t+EpGgM0A+93cItEwIl8YPu
 jrcjhIUjK7jE+f1AL8FVUlCMoXCQalUGlLQgaw0SCNWPEqCySysikwIZlpV03fBWB1V1YukI6
 Khj0vsJmu7Z6xz963756xggPlyAUvANJEO/+sk6ie6L2paq5qooI1skBfvfY8pQ8efEu6Pxuo
 DTOKhqORN0OF4yL67XDowaRIFdNn1j//pX1etK+2zu7n5ZaKcv2zbY2qSNZOLtYxOOyyel1pC
 vfYkOndNiMWE5hUs0WokXHtuD1IGt1sMlKMAyw8MGomJBGWS6+sT1WoGT2Lqfv9Yap1eABD3m
 TjvNjkL/GnwSznKlvqNnfPT0m+cXLJhxJMs1f2Iw+arE1KPZqJe0RjLZEmaglOYPTDvVu30Yg
 CXDEcf8VsW0wF2cfazi3z9pUwqqBFrBYacg4xUIIyTv2arTqei/NE7GxX+mpmgdopBJbm8rqA
 gQxgdFEr41DjgWUEt1E+jtxBiV0QhJ5kOm3CcuUAsHd0D38N4ve/tJBSx8+eARF2MR9ocJBrJ
 SkVIEcOTunDaWQWBH/0LNcmVgm3Kw==
X-Spam-Score: -1.5 (-)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.5 (-)

 > 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.

 > 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.

 > 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).

 >> 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.

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 20:28:57 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 16:28:57 2017
Received: from localhost ([127.0.0.1]:49425 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czUJV-0007Qx-Jy
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 16:28:57 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:55203)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1czUJT-0007Ql-OD
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 16:28:56 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id 0EB9B223E6
 for <26513 <at> 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
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 <at> debbugs.gnu.org>;
 Sat, 15 Apr 2017 20:24:58 +0000 (UTC)
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)
From: charles@HIDDEN (Charles A. Roelli)
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN> <58F23339.6090201@HIDDEN>
 <m2inm5trdt.fsf@HIDDEN> <58F27723.8010706@HIDDEN>
Date: Sat, 15 Apr 2017 22:28:46 +0200
In-Reply-To: <58F27723.8010706@HIDDEN> (martin rudalics's message of "Sat, 15
 Apr 2017 21:40:19 +0200")
Message-ID: <m24lxptny9.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 20:05:53 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 16:05:53 2017
Received: from localhost ([127.0.0.1]:49405 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czTxB-0006uG-GK
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 16:05:53 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:55179)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1czTx9-0006u2-8w
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 16:05:52 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id 8BAB3223E6
 for <26513 <at> 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
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 <at> debbugs.gnu.org>;
 Sat, 15 Apr 2017 20:01:50 +0000 (UTC)
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)
From: charles@HIDDEN (Charles A. Roelli)
To: Drew Adams <drew.adams@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
 <7e856815-6dff-4152-b144-c45a4bedb0b4@default>
Date: Sat, 15 Apr 2017 22:05:39 +0200
In-Reply-To: <7e856815-6dff-4152-b144-c45a4bedb0b4@default> (Drew Adams's
 message of "Sat, 15 Apr 2017 09:49:28 -0700 (PDT)")
Message-ID: <m2efwttp0s.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 19:40:39 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 15:40:39 2017
Received: from localhost ([127.0.0.1]:49392 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czTYl-0006KF-02
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 15:40:39 -0400
Received: from mout.gmx.net ([212.227.15.19]:52100)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1czTYj-0006K2-Bx
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 15:40:37 -0400
Received: from [192.168.1.100] ([213.162.68.102]) by mail.gmx.com (mrgmx002
 [212.227.17.190]) with ESMTPSA (Nemesis) id 0M5Lmp-1c7MEp263T-00zWjt; Sat, 15
 Apr 2017 21:40:24 +0200
Message-ID: <58F27723.8010706@HIDDEN>
Date: Sat, 15 Apr 2017 21:40:19 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: "Charles A. Roelli" <charles@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN> <58F23339.6090201@HIDDEN>
 <m2inm5trdt.fsf@HIDDEN>
In-Reply-To: <m2inm5trdt.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:VnGZ92/iNV6mO7qkMH3gLR5PZnlM+9IlWcnbzYhfYBrgPy5rIlL
 kupj1PiFdy0COQWFXfBtTY6XZpnBpDSQcbQHAciH27X6Mw6UOpJNzafwykcvI2kes9njz2k
 WGlpnOJvpauRqnh2OaHJBQ6YgtxcJny6HeweHvJJndFQX9MBXTamQxS38UStpDf6g7MFXCo
 JVDPQy1cBl0BqBbRlCwrQ==
X-UI-Out-Filterresults: notjunk:1;V01:K0:diWZgHcFiRc=:IXZ0x6rL/8z6kG0SKlfPLQ
 LSsO4/nBx8P+8O7IdrAXuzcdy3mAUb1ssCM+ESgivHag+/lD6lVZeJOtfQpMtOfjmZD3n/hdV
 /5CPNJ3dT/RLkZ78N8wwcUwOM4rQ/SZQFBcCwPeLmnW2nbDOth1+mZ4ll/PRAims28FuSaJq8
 Kegqv4aPrgYGyrruHz7vKtAlnsuAU06kUiIbg+B4NaWNEmTPD19l8X7P/E36mHAnB8IpzSLox
 p9Kniw9h7PRe/fRLtjCYrhS9AJX8NI/+n59sW7e+DFbDnjIvfEbfmbKSFfHjt43hl7OB/rNTx
 6VU3O43Dtn9kfTs1XYv9QA+q9Ygg9WRoLkvLmEBUIj1zUZH6Rv0Eq89ugulpVymJyOcSLonEw
 xmqgUZ4yjPofmN9ykMYvDKaJN+cmW2gVEzwLgVOxSmTlC4CnWLlsgmg3CoaHwwgiurIQ4ogad
 l1sittPtPx4u3A2tAk6Gp+D4GgyL2CEReBqiMqPsm0MTvDodw0wxNHmyrfO64GdJoqkYixhJL
 VIW3lkh5b45uOLDRMM+YOX6pPw+YXAB9dE3DJdQv/OFg3uY/KVZgxGBDsQ56u5qDzdPoOb2HL
 kLrIJyGfQmyUyJUp4Sq30yJWNfxYXXUGYZGLDYceZAAc8OqVFt6h4yrGTAKDNhZ4aZoqIQrOV
 WkClGYf0Gd0tTnQ6wn52JtOIjdiWrs5y5EOTRCNoJRYF4ZEjlzpWLYAiACqG6pSKiltaRPOCH
 eP2t5bKbKluZhxdmZt/zhutfWIAf3Hd3wKEfn3gFOCV1SjggaP/HvkoqS5EVh1uoR/Hhrg6XU
 dphlTo8wqeVujEw/tsIHaExuTbllQ==
X-Spam-Score: -2.0 (--)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.0 (--)

 > (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.

 > 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.  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?

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 19:14:50 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 15:14:50 2017
Received: from localhost ([127.0.0.1]:49371 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czT9l-0005hX-TE
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 15:14:50 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:55125)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1czT9k-0005hJ-EJ
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 15:14:49 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id 159A7223E6
 for <26513 <at> 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
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 <at> debbugs.gnu.org>;
 Sat, 15 Apr 2017 19:10:50 +0000 (UTC)
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)
From: charles@HIDDEN (Charles A. Roelli)
To: martin rudalics <rudalics@HIDDEN>
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN> <58F23339.6090201@HIDDEN>
Date: Sat, 15 Apr 2017 21:14:38 +0200
In-Reply-To: <58F23339.6090201@HIDDEN> (martin rudalics's message of "Sat, 15
 Apr 2017 16:50:33 +0200")
Message-ID: <m2inm5trdt.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -0.7 (/)
X-Debbugs-Envelope-To: 26513
Cc: 26513 <at> debbugs.gnu.org
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -0.7 (/)

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.




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 16:49:51 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 12:49:51 2017
Received: from localhost ([127.0.0.1]:49192 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czQtT-00057k-EF
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 12:49:51 -0400
Received: from userp1040.oracle.com ([156.151.31.81]:39401)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <drew.adams@HIDDEN>) id 1czQtR-00057W-Ne
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 12:49:50 -0400
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
 v3FGnX9F004850
 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK);
 Sat, 15 Apr 2017 16:49:34 GMT
Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235])
 by userv0022.oracle.com (8.14.4/8.14.4) with ESMTP id v3FGnWVX006455
 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK);
 Sat, 15 Apr 2017 16:49:33 GMT
Received: from abhmp0017.oracle.com (abhmp0017.oracle.com [141.146.116.23])
 by aserv0121.oracle.com (8.13.8/8.13.8) with ESMTP id v3FGnS1F010908;
 Sat, 15 Apr 2017 16:49:30 GMT
MIME-Version: 1.0
Message-ID: <7e856815-6dff-4152-b144-c45a4bedb0b4@default>
Date: Sat, 15 Apr 2017 09:49:28 -0700 (PDT)
From: Drew Adams <drew.adams@HIDDEN>
To: charles@HIDDEN, 26513 <at> debbugs.gnu.org
Subject: RE: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
In-Reply-To: <m2d1ce81yl.fsf@HIDDEN>
X-Priority: 3
X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1  (1003210) [OL
 12.0.6753.5000 (x86)]
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Source-IP: userv0022.oracle.com [156.151.31.74]
X-Spam-Score: -2.3 (--)
X-Debbugs-Envelope-To: 26513
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

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.

I've tried to do what I can in my own environment to
handle this, especially in the context of a standalone=20
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*")=20
                         completion-reference-buffer))
                (window-frame
                  (get-buffer-window
                    completion-reference-buffer t))))))
      (when redirect
        (redirect-frame-focus (selected-frame)
                              redirect)))

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.

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.

The other reason is probably just because few Emacs
users try to use separate frames by default, or if
they try they soon give up due to the many hurdles.

Anyway, you might try, to start with, redirecting
the frame focus back to `completion-reference-buffer'.

For reference, in case it helps, my code for
`1on1-display-*Completions*-frame' is in `oneonone.el'
(https://www.emacswiki.org/emacs/download/oneonone.el).
My code for keybindings in `completion-list-mode-map'
is in `icicles-mode.el'
(https://www.emacswiki.org/emacs/download/icicles-mode.el).




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at 26513 <at> debbugs.gnu.org:


Received: (at 26513) by debbugs.gnu.org; 15 Apr 2017 14:50:52 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 10:50:52 2017
Received: from localhost ([127.0.0.1]:49095 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czP2K-0002KG-8G
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 10:50:52 -0400
Received: from mout.gmx.net ([212.227.17.20]:64156)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1czP2J-0002K3-3Y
 for 26513 <at> debbugs.gnu.org; Sat, 15 Apr 2017 10:50:51 -0400
Received: from [192.168.1.100] ([213.162.68.80]) by mail.gmx.com (mrgmx101
 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lip2P-1cTvhD1RTZ-00cv5H; Sat, 15
 Apr 2017 16:50:38 +0200
Message-ID: <58F23339.6090201@HIDDEN>
Date: Sat, 15 Apr 2017 16:50:33 +0200
From: martin rudalics <rudalics@HIDDEN>
MIME-Version: 1.0
To: "Charles A. Roelli" <charles@HIDDEN>, 26513 <at> debbugs.gnu.org
Subject: Re: bug#26513: 25.2; pop-up-frames and *Completions* buffer
References: <m2d1ce81yl.fsf@HIDDEN>
In-Reply-To: <m2d1ce81yl.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K0:sscv3+97oldTaVD+VHClLnEMLtzVitPsqgp6fFTvkTAmCPz7sxd
 SswzffkuOM21wSsJtyLvMcsEUGiorhM15g0gify2vmTlJwSHBwGODIf9Eov3R0JklwdVdYo
 NSU0gYyPfscvmuQyfJNBMwPJhQUzvmXeoWGD6m9a61RFWyMIkyJCI6svEfC0968rwyku1c+
 4Rgk/3H6ZBzLIE7ddQo4w==
X-UI-Out-Filterresults: notjunk:1;V01:K0:vS14Vz5EAT0=:ZlRSe71uxhfyKu3tM8qlT7
 JOnIpdfiGx6EFidNelAwVB2Q1Gsw5+RwM9YzghjDk4nQ8F7AdqK2ol6wb/jThzik9H8GdCVXx
 Ezta/UTJ3qSr1HKvCmlttsywwyQTs0LvRANI5Uyrl3mwB6x/ISkSQV9gVhejgrDnLW22HC/6v
 WvyU59s0n6n0HbOIqCffMg1DK4FQBNbm3e5jRdaQBGxTNCD0EWc/aAb0OgryPW89opYeLNSZA
 ySMRnStMU8JlK4I+awX8BWijg41BWoJysAWkOkuLMsB63xlmcywlW4f55h3GBK7ypGi8R6eb2
 7qCYFGZNxt3aFeFxIN0Nb2zMZZ5XIrAHf0obIuN0VK29kfNyNTLh+doCxDLAeCGIh5C+bW4qS
 smLG+RyyNKuztLI42OrZkslT7nkEh1Kq5z1a2IBhr39nYtsh/L7cI5TP9cToVYNd1rF8pOEc1
 tBivNNHfwMJbLaevPQHtfJDh7sSLygjEfRxDs0n/as6azydCmn+2CcodtfCAJRBILDldAbTN0
 zl4yu+mzhNbuzYaFq/tjs5Zne2gNdp1jvHRiOqO5zmzauLgNIm11+6SitiMr7JpRg0bS7MeM4
 X7TDEgU9nTfz0ekwVyrwsMRn8wqWi936gYFLSgi/mZRxGkWSRrzDgn8SicCBJx4Mew1QmY9y8
 YGyMgMQWnDXKJjCkiILE1JQgk8Se6Sq1nWYcMjNYGySVg6Pn6wq/7koeyj9bjzMouad4KRS/h
 5Wen30N9Gw9sobnhZeURBE3sqdLQa3ypYKYHN7V1aVCRAh2Sr7OB4UtKYSanTFpCa9e88tPNX
 grR4+cc4m5Z0bd1V8D3v6ZvUOK0Ww==
X-Spam-Score: 0.8 (/)
X-Debbugs-Envelope-To: 26513
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 0.8 (/)

 > 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?

martin




Information forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.

Message received at submit <at> debbugs.gnu.org:


Received: (at submit) by debbugs.gnu.org; 15 Apr 2017 09:17:31 +0000
From debbugs-submit-bounces <at> debbugs.gnu.org Sat Apr 15 05:17:31 2017
Received: from localhost ([127.0.0.1]:47846 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1czJpj-0007SQ-Cc
	for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 05:17:31 -0400
Received: from eggs.gnu.org ([208.118.235.92]:51723)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <charles@HIDDEN>) id 1czJph-0007SD-Qz
 for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 05:17:30 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <charles@HIDDEN>) id 1czJpb-0004Lo-ON
 for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 05:17:24 -0400
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org
X-Spam-Level: 
X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,T_DKIM_INVALID
 autolearn=disabled version=3.3.2
Received: from lists.gnu.org ([2001:4830:134:3::11]:42301)
 by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <charles@HIDDEN>) id 1czJpb-0004Lg-L5
 for submit <at> debbugs.gnu.org; Sat, 15 Apr 2017 05:17:23 -0400
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42687)
 by lists.gnu.org with esmtp (Exim 4.71)
 (envelope-from <charles@HIDDEN>) id 1czJpa-0008Cn-LO
 for bug-gnu-emacs@HIDDEN; Sat, 15 Apr 2017 05:17:23 -0400
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
 (envelope-from <charles@HIDDEN>) id 1czJpX-0004Jd-GH
 for bug-gnu-emacs@HIDDEN; Sat, 15 Apr 2017 05:17:22 -0400
Received: from sinyavsky.aurox.ch ([37.35.109.145]:60841)
 by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32)
 (Exim 4.71) (envelope-from <charles@HIDDEN>) id 1czJpX-0004HC-8E
 for bug-gnu-emacs@HIDDEN; Sat, 15 Apr 2017 05:17:19 -0400
Received: from sinyavsky.aurox.ch (sinyavsky.aurox.ch [127.0.0.1])
 by sinyavsky.aurox.ch (Postfix) with ESMTP id C89CD223E6
 for <bug-gnu-emacs@HIDDEN>; Sat, 15 Apr 2017 09:13:18 +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:date:date
 :subject:subject:to:from:from; s=dkim; t=1492247597; x=
 1493111598; bh=2QCJmQAnJZQrynAxJfimcPIIHwEwmOe4vTTA1vhAI04=; b=B
 YbhodGtq10V7/gkbYvoYVhJQKyVQyoI+5jr4+3InP7TyrbB9pgZIgU8Cu393do7F
 X7AFyWI5vugpoFso6JYpcwk92dGYiwff6J+xN3mqqnM9DpriiSb1pTDO+16PphTZ
 tlZcR9+uD5W2mVFNkXhv9pHMoLCZNXS0BNQbUI/x6Q=
X-Virus-Scanned: Debian amavisd-new at test.virtualizor.com
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 6aI5dVUtEmeD for <bug-gnu-emacs@HIDDEN>;
 Sat, 15 Apr 2017 09:13:17 +0000 (UTC)
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 69149223E4
 for <bug-gnu-emacs@HIDDEN>; Sat, 15 Apr 2017 09:13:17 +0000 (UTC)
From: charles@HIDDEN (Charles A. Roelli)
To: bug-gnu-emacs@HIDDEN
Subject: 25.2; pop-up-frames and *Completions* buffer
Date: Sat, 15 Apr 2017 11:17:06 +0200
Message-ID: <m2d1ce81yl.fsf@HIDDEN>
MIME-Version: 1.0
Content-Type: text/plain
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic]
 [fuzzy]
X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x
X-Received-From: 2001:4830:134:3::11
X-Spam-Score: -4.1 (----)
X-Debbugs-Envelope-To: submit
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -4.1 (----)

From emacs -Q:

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?

In GNU Emacs 25.2.1 (x86_64-apple-darwin10.8.0, NS appkit-1038.36 Version 10.6.8 (Build 10K549))
 of 2017-02-22 built on gray
Windowing system distributor 'Apple', version 10.3.1038
Configured using:
 'configure --with-modules'

Configured features:
JPEG RSVG NOTIFY ACL GNUTLS LIBXML2 ZLIB TOOLKIT_SCROLL_BARS NS MODULES




Acknowledgement sent to charles@HIDDEN (Charles A. Roelli):
New bug report received and forwarded. Copy sent to bug-gnu-emacs@HIDDEN. Full text available.
Report forwarded to bug-gnu-emacs@HIDDEN:
bug#26513; Package emacs. Full text available.
Please note: This is a static page, with minimal formatting, updated once a day.
Click here to see this page with the latest information and nicer formatting.
Last modified: Mon, 25 Nov 2019 12:00:02 UTC

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997 nCipher Corporation Ltd, 1994-97 Ian Jackson.