unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: martin rudalics <rudalics@gmx.at>,
	Lars Ingebrigtsen <larsi@gnus.org>,
	"Charles A. Roelli" <charles@aurox.ch>
Cc: Stefan Monnier <monnier@iro.umontreal.ca>,
	"26513@debbugs.gnu.org" <26513@debbugs.gnu.org>
Subject: bug#26513: [External] : bug#26513: 25.2; pop-up-frames and *Completions* buffer
Date: Thu, 17 Feb 2022 16:40:20 +0000	[thread overview]
Message-ID: <SJ0PR10MB5488C9B25950D2B0BC86BEC6F3369@SJ0PR10MB5488.namprd10.prod.outlook.com> (raw)
In-Reply-To: <066f0fac-2ce9-fe9a-355f-e148953fc6f0@gmx.at>

>>> >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.
>>
>> This problem is still present in Emacs 29.  I guess the general solution
>> here would be for completion to ensure that it's gotten focus back again
>> after displaying the *Completions* buffer?
> 
> Maybe Stefan Monnier can tell us what he does in such case.
> 
> I can offer the attached, largely untested patch.  A possible
> customization would then be
> 
> (customize-set-variable
>   'display-buffer-alist
>   '(("*Completions*"
>      (display-buffer-reuse-window
>       display-buffer-pop-up-frame)
>      (reusable-frames . t)
>      (redirect-frame-focus . t))))

22 years ago I reported this problem.
I fixed it for my use in this way...
 
tl;dr:

Use a standalone minibuffer frame, and a
separate frame for `*Completions*' that's
displayed with a function that does this:

(redirect-frame-focus (selected-frame)
                      1on1-minibuffer-frame)
___

In my code I do this by adding function
`1on1-display-*Completions*-frame' to
`special-display-buffer-names'.  What it does:

1. `redirect-frame-focus' to the standalone
minibuffer frame if the minibuffer is active, or
to `completion-reference-buffer' (unless it's
`*Completions*') otherwise.

2. Return the window resulting from calling the
value of `special-display-function' at the start
of `1on1-display-*Completions*-frame'.
___

It does other stuff as well, which is why it
needs, at the outset, to get the window to
return:
It optionally uses the same font family for
`*Completions*' as the frame selected when the
minibuffer was set up.  It optionally shrinks
the text in `*Completions*' by a user-defined
amount.  It optionally repositions frame
`*Completions*' to the right edge of the
display temporarily, to make both it and the
original frame more visible.
___

(`display-buffer-alist' could presumably be
used instead of special-display.  I don't use
it because special-display is simpler and it's
available also for older Emacs releases that
don't have `display-buffer-alist'.)
___

The code I use is in `oneonone.el':

https://www.emacswiki.org/emacs/download/oneonone.el

      parent reply	other threads:[~2022-02-17 16:40 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-04-15  9:17 bug#26513: 25.2; pop-up-frames and *Completions* buffer Charles A. Roelli
2017-04-15 14:50 ` martin rudalics
2017-04-15 19:14   ` Charles A. Roelli
2017-04-15 19:40     ` martin rudalics
2017-04-15 20:28       ` Charles A. Roelli
2017-04-16  7:16         ` martin rudalics
2017-04-17  7:44           ` Charles A. Roelli
2017-04-15 16:49 ` Drew Adams
2017-04-15 20:05   ` Charles A. Roelli
2017-04-16 15:54     ` Drew Adams
2017-04-18 17:27       ` martin rudalics
2017-04-18 20:34       ` Charles A. Roelli
2017-04-19  7:26         ` martin rudalics
2022-02-15 10:37 ` Lars Ingebrigtsen
2022-02-17 10:01   ` martin rudalics
2022-02-17 13:13     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-17 16:02       ` martin rudalics
2022-02-17 19:21         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-02-19  9:40           ` martin rudalics
2022-02-19 12:23             ` Eli Zaretskii
2022-02-20  0:25               ` bug#26513: [External] : " Drew Adams
2022-02-20  0:28             ` Drew Adams
2022-02-20  9:17               ` martin rudalics
2022-02-20 21:16                 ` Drew Adams
2022-02-21 16:25             ` Drew Adams
2022-02-17 16:40     ` Drew Adams [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=SJ0PR10MB5488C9B25950D2B0BC86BEC6F3369@SJ0PR10MB5488.namprd10.prod.outlook.com \
    --to=drew.adams@oracle.com \
    --cc=26513@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    --cc=larsi@gnus.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).