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

Hi Drew,

On Sun, Apr 16 2017 at 08:54:37 am, Drew Adams wrote:

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

Thanks for this minimal example.

It also doesn't work for me on Emacs 25 either.  Emacs 24.4 does work
fine, however.  I have no clue why... maybe redirect-frame-focus has
changed in Emacs 25?

Here is the recipe I used to check if it worked:

    emacs -Q
    load your two functions
    M-x foo
    M-x global- TAB auto

Typing "auto" resulted in a "Buffer is read-only: #<buffer
*Completions*>" error when the redirection wasn't working.  When the
redirection did work, the "auto" keyboard input was correctly sent to
the minibuffer.  I also tried Martin's suggestion of removing the
(select-window) call but that didn't get rid of the error for me.

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

Yep, seems to be the case for most window managers.  I never noticed
this before.

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

And that's what Emacs is built on. :D





  parent reply	other threads:[~2017-04-18 20:34 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 [this message]
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=m2efwpmp4d.fsf@aurox.ch \
    --to=charles@aurox.ch \
    --cc=26513@debbugs.gnu.org \
    --cc=drew.adams@oracle.com \
    /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).