unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Drew Adams <drew.adams@oracle.com>
To: charles@aurox.ch
Cc: 26513@debbugs.gnu.org
Subject: bug#26513: 25.2; pop-up-frames and *Completions* buffer
Date: Sun, 16 Apr 2017 08:54:37 -0700 (PDT)	[thread overview]
Message-ID: <ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default> (raw)
In-Reply-To: <m2efwttp0s.fsf@aurox.ch>

> 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.
> 
> Yes, this seems like it's the main issue here.  But 
>still, sane frame behavior doesn't seem too far off.

Hope springs eternal. ;-)





  reply	other threads:[~2017-04-16 15:54 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 [this message]
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=ffe2bbc7-a89d-4ce4-9063-22c205b9b44e@default \
    --to=drew.adams@oracle.com \
    --cc=26513@debbugs.gnu.org \
    --cc=charles@aurox.ch \
    /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).