On Sat, Dec 16, 2017 at 11:15 AM, Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Robert Weiner <rsw@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?

​​
> 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?
​

> ​​
>   And there are
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
> ​​
>
> ​​
> other, more subtle use cases.
>

​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?
​

> ​
>
> ​​
> In general, Lisp programs shouldn't dictate the display engine what to
> ​​
> do or not to do, because they can easily make mistakes, being unaware
> ​​
> of all the subtleties.  Instead, it should be the job of the display
> ​​
> engine to determine what and when to redraw, and Lisp can at most
> ​​
> provide hints.
>

​Right, this is what we do most of the time.
​

> ​​
>
> ​​
> > I don't think Elisp programmers should have to
> ​​
>
> ​​
> > master the intricacies of windows, frames, the
> ​​
> redisplay engine,
> ​​
> > and window managers to do that.
> ​​
>
> ​​
>
> ​​
> They don't.  But note that your code
> ​​
> attempted to do just that, at
> ​​
> least indirectly.
> ​​
>

​I am trying to do just what I stated above plus ensure
the displayed frame receives input focus.​
​​

> ​​
> >  ​​On top of th
> ​​
> at, when and how a new frame appears on display is not
> ​​
> >  ​​only up to E
> ​​
> macs: the WM has a lot to do with that.
> ​​
> >
> ​​
>
> ​​
> >
> ​​
> ​Yes, but Emacs sends commands to the WM.  Now if the WM ignores
> ​​
> >
> ​​
> those commands not much can be done
> ​​
>
> ​​
> The problem is, many popular WMs do ignore our hints.  So reliable
> ​​
> behavior cannot be built on top of this flaky basis.
>

Under what window managers is Emacs unable to raise
a frame or set input focus reliably?  That sounds like
a platform where multi-frame use would be generally
unreliable.
​

> ​​
>
> ​​
> > Take raise-frame for example.  Should we not expect
> ​​
> > this to make the given frame the topmost?  The doc string says we
> ​​
> > should.
> ​​
>
> ​​
> Martin will tell, but I personally am not sure we can rely on that,
> ​​
> the doc string notwithstanding.
>

​If you cannot put a frame in front of all others then
you can't see the contents of its windows when frames
overlap and again multi-frame​ use would not be viable
except for non-overlapping frames.

​​
>
> ​​
> >  ​​The doc strings try very hard to tell the story completely and
> ​​
> >  ​​accurately, but it isn't easy, because the underlying behavior is
> ​​
> >  ​​extremely complex, and needs to cater to some very different use
> ​​
> >  ​​cases.
> ​​
> >
> ​​
> > ​I'm mainly asking that obvious gotchas like those demonstrated
> ​​
> > by my sample code be mentioned in doc strings, not a deep dive
> ​​
> > into all special case technicalities.
> ​​
>
> ​​
> But the doc strings need to provide information for much more complex
> ​​
> code as well, not just for simple codes.
>

​I'm not against documenting more involved scenarios,
just saying I think some of this documentation could
be added with a few sentences without diving deeply
into many special cases.  If this covered 90% of the
cases, it would still be very helpful despite not being
wholly complete.  You yourself said earlier that that
is an unreasonable expectation of the doc.
​

> ​​
>
> ​​
> >  ​​Calling 'redisplay' with last argument non-nil is the o
> ​​
> nly way to
> ​​
> >  ​​actually ensure redisplay, so if you must, use only th
> ​​
> at.
> ​​
> >
> ​​
>
> ​​
> >
> ​​
> ​It sounds like that is the only way since I need to see the current
> contents
> ​​
> >
> ​​
> of the new frame's only window.
> ​​
>
> ​​
> A
> ​​
> nd what's wrong with that?  You don't need more than one way, as long
> ​​
> a
> ​​
> s it works.
>

​It is fine.  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.  So I looked for other techniques to
give redisplay hints as you said and was surprised when these
hints were insufficient.​

Bob