unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





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