On Sat, Dec 16, 2017 at 2:45 PM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Sat, 16 Dec 2017 13:57:34 -0500
> > Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>
> >
> >  > ​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