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 21:14:38 +0200	[thread overview]
Message-ID: <m2inm5trdt.fsf@aurox.ch> (raw)
In-Reply-To: <58F23339.6090201@gmx.at> (martin rudalics's message of "Sat, 15 Apr 2017 16:50:33 +0200")

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.





  reply	other threads:[~2017-04-15 19:14 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 [this message]
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

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