Re: select-frame-set-input-focus fails to raise the frame

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2448 bytes --]

On Fri, Dec 15, 2017 at 3:44 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Fri, 15 Dec 2017 12:38:15 -0500
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>
> >
> > ​The problem was that I would set-window-buffer in the new frame
> > to a different buffer and that buffer would not display when
> > the new frame was brought frontmost and displayed temporarily
> > with a sleep-for delay.  Calling force-window-update had no
> > effect but calling (redisplay t) resolved it.
>
> What do you mean by "displayed temporarily"?  As long as the current
> command runs, Emacs will not enter redisplay; an explicit call to
> 'redisplay' is the only exception to that rule.  So it sounds like
> ​​
> what you describe is Emacs working as designed.
>
​​
​By displayed temporarily, I mean that new frame f2 and old
frame f1 largely overlap one another and I want f2 to appear
above f1 for a given delay, like half a second and then f1
to be raised atop it.​

I should have noted that I first tried force-window-update (doc string
says it marks the given window to be redisplayed the next time redisplay
runs) followed by a sit-for (doc string says it runs redisplay
unconditionally
until at least until any further input or timer expiration).  That
combination
did not work either.  Only the explicit call to redisplay worked.  This
seems
to conflict with the doc strings to me.  If you look at the functions I have
enclosed, you will see the behavior I am trying to produce.

My broader argument is that one should be able to program utilizing
window-based
functions more simply when the windows involved exist in separate frames
and an
external window manager is involved.  However, I see not everyone agrees
with this,
maybe because some of the behavior will always be asynchronous and possibly
non-deterministic.

Previously, I found Emacs handled mouse button drags between windows in
different frames
differently than drags between windows in a single frame.  I was able to
figure out a
consistent model that now works well for me.  I think this is similar, that
with some
work, managing windows across multiple frames can be made simpler and
less-error
prone than the way things are now.  But if the major maintainers of Emacs
are not very
interested in this, then I don't expect anything to happen.

Bob

​​

[-- Attachment #2: Type: text/html, Size: 5337 bytes --]