[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#43672: 28.0.50; select-frame-set-input-focus does not set focus firs
From: |
Arthur Miller |
Subject: |
bug#43672: 28.0.50; select-frame-set-input-focus does not set focus first time called |
Date: |
Sun, 18 Oct 2020 16:10:44 +0200 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
martin rudalics <rudalics@gmx.at> writes:
>> sorry for being a bit late with this. I have tested and it was very
>> strange, so I realized I need more time to play with it.
>>
>> Here is how I got it:
>>
>> If I pass parent in the frame-params list to make-frame, then all is
>> grandy-dandy;
>
> Even without emacsclient?
No I tested emacsclient only; didn't have time to test more I had to go
to sleep :-)
>> but if I don't then the behaviour is as following:
>>
>> If parent is set after creation; the frame will be reparented correctly
>> and appear at correct place on the screen, but it won't switch focus.
>
> But it eventually does get focus if you insist by executing
> 'select-frame-set-input-focus' twice. Right?
Yes. I think I said that previously; tested now and it works when
setting focus twice.
>> If parent is not set after the creation; the frame will switch focus,
>> buf it will of course appear somewhere at the screen (absolute
>> coordinates I guess).
>>
>> I have tested only emacsclient. I hope it helps.
>
> Earlier you said:
>
> It works correctly in emacsclient; not correctly when I run Emacs as a
> standalone process, either with -Q flag or without.
>
> So shouldn't you try with a standalone Emacs?
Yes I know; but now I get the behaviour as described in the previous
mail in client too.
I have just tested with emacs -Q too, and I get same behaviour, so at
least now it seems to behave same in both client and standalone process.
>> I have attached a simplified test file:
>
> If setting the parent in 'make-frame' works, then we can warn about
> reparenting later possibly causing problems with focus transfer. But
> if
Personally I can live with this, it is not problem for me; I reported
mostly because I thought it was rather an odd behaviour. I understand
it's a picky thing to debug.
> But if
> the problematic behavior occurs when you want to pop up an (already
> existing but invisible) child menu frame on a different parent and give
> the menu focus, I have no idea what to do. So does the latter work for
> you?
I haven't come to that part yet :-). I just started to write a small
eperiment, got into that one and reported, and haven't had time to go
back to my experiment.