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

[Robert Weiner]

On Fri, Dec 15, 2017 at 3:44 PM, Eli Zaretskii <address@hidden> wrote:

> From: Robert Weiner <address@hidden>
> Date: Fri, 15 Dec 2017 12:38:15 -0500
> Cc: Alan Third <address@hidden>, emacs-devel <address@hidden>
>
> ​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

​​