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