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

[Robert Weiner]

On Sat, Dec 16, 2017 at 2:45 PM, Eli Zaretskii <address@hidden> wrote:

> From: Robert Weiner <address@hidden>
> Date: Sat, 16 Dec 2017 13:57:34 -0500
> Cc: Alan Third <address@hidden>, emacs-devel <address@hidden>
>
>  > ​Ok, that is an example of why I am advocating for a potentially
>  > new function that let's a programmer say "display the latest
>  > contents of this window with no other Emacs window or frame
>  > obscuring it".
>
>  That cannot be done in general, because redisplaying a window could
>  very well affect other windows.  One example of that is TTY frame
>  display;
>
> ​Only one frame is visible on a tty at a time, so in
> my use case, this would have to be the frame that
> displays the window.  Why is this a problem?

TTY redisplay deals with the entire frame, so it cannot redraw a
single window.

​Again, I think you are missing my main points because you are

drawn to the implementation level.  ​I never said redisplay had

to only draw one window.  I said that I needed the latest contents

of a particular window displayed.  I don't care what redisplay feels

it needs to redraw as long as it shows the latest contents of that

window, it does it at a particular point in the function and Emacs

tells the window manager to make its frame the uppermost in the stack

or Z-frame group as Martin described).

​​

​​

>  ​​another is a case where the window was shrunk.

​​

>

​​

> ​Why can a shrunk window not be displayed within the

​​

> topmost frame?  You are giving examples without explaining

​​

> why they conflict with the desired goal?

​​

​​

I gave examples that explain why Emacs cannot be in general told to
redraw a single window.  Maybe I misunderstood, but I thought this is
what you were trying to accomplish ("display the latest contents of
this window").

​No.  I mentioned the latest contents of the window because

when I used sit-for to trigger redisplay, I would see the

new frame displayed with the buffer it was created with even

though a set-window-buffer change had been called prior to

the invocation of the sit-for.  So just displaying the window

was insufficient since it had the wrong contents.  Calling

(redisplay t) directly fixed this.

​​

> ​So you are saying Emacs provides no way for the programmer

​​

> to ensure that a window is wholly displayed on screen and

​​

> fully updated even when Emacs is the only application in use?

​​

​​

Not if you want to tell Emacs to display _only_ one window.

​Okay, this was just you misreading my intent.

> I had just dealt with many multi-frame scenarios
> before and never had to call redisplay directly so it seemed
> odd that I had to now.

That's because normally, you don't need to.  Having to display changes
during the command's execution is a rare use case.

​But it will come up any time a temporary display of an

overlapping frame is necessary where the function must

end with another frame atop the stack.  Thus, it sounds like

a case for a with-temp-frame macro that would call

select-frame-set-input-focus on the temp frame for a variable

specified amount of time.  It would then reset the selected frame

and input focus to the way they were prior to the macro invocation

(as best it could given system limitations).

Bob