From: charles@aurox.ch (Charles A. Roelli)
To: martin rudalics <rudalics@gmx.at>
Cc: 26513@debbugs.gnu.org
Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer
Date: Sat, 15 Apr 2017 22:28:46 +0200 [thread overview]
Message-ID: <m24lxptny9.fsf@aurox.ch> (raw)
In-Reply-To: <58F27723.8010706@gmx.at> (martin rudalics's message of "Sat, 15 Apr 2017 21:40:19 +0200")
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.
next prev parent reply other threads:[~2017-04-15 20:28 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 [this message]
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
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=m24lxptny9.fsf@aurox.ch \
--to=charles@aurox.ch \
--cc=26513@debbugs.gnu.org \
--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).