GNU bug report logs - #43672
28.0.50; select-frame-set-input-focus does not set focus first time called

Previous Next

Full log

Message #11 received at 43672 <at> debbugs.gnu.org (full text, mbox):

From: Arthur Miller <arthur.miller <at> live.com>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: 43672 <at> debbugs.gnu.org
Subject: Re: bug#43672: 28.0.50; select-frame-set-input-focus does not set
 focus first time called
Date: Mon, 28 Sep 2020 16:11:48 +0200

Lars Ingebrigtsen <larsi <at> gnus.org> writes:

> Arthur Miller <arthur.miller <at> live.com> writes:
>
>> When calling
>>
>>       (select-frame-set-input-focus some-frame)
>>
>> the frame is raised, but does not recieve the focus.
>
>
> [...]
>
>> (define-minor-mode pm-minor-mode
>>   :keymap (let ((map (make-sparse-keymap)))
>>             map))
>
> This isn't valid (lacks a doc string),
Ah, ok; It was just a quickie to let me close menu without M-x
delete-frame when I test.

> but after fixing it, I'm unable
> to reproduce the bug?  I think?  At least my frame lost focus, but the
> other frame never really appeared in any visible sense. Can
it be it just ended somewhere outside the screen?

Did you run via the "test" function (pm-test)? It should take pixel
coordinate of the point and try to place the frame at those coords.

> It did something really weird to my Gnome Shell desktop -- even after
> closing the Emacs that opened the frames, Gnome Shell insists that
> they're there, but not responding.
That sounds really weird. The code does notthing special; it just
creates a child frame, and tries to display a buffer in it.

On my machine (I use Compiz as WM), it displays properly, either at
point or cursor. It is just that focus does not get transfered as
advertised (as I understand it).

Thanks for looking at it.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.