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

>
> > No frame change has occurred yet
> > where user input like self-inserting characters goes is different.
> > How can this not be part of your Emacs model?
>
> As long as the selected frame is unchanged, the model holds: you need
> only select the window.
>
> > ​​Frame-level input focus is insufficient to describe the window to which
> > keyboard input goes in all cases.
>

​We were talking about how input focus was an insufficient
concept to describe which window user input is directed to.
Similarly, select-window is insufficient by itself as well.
​

> ​​
>
> ​​
> Keyboard input goes to the selected window of the selected frame.
> ​​
> Why isn't that description sufficient?
>

​Where is that explained?  How does one find it?
​

> ​​
>
> ​​
> > Plus, if we want to see any changes in buffer-to-window mappings
> ​​
> > during the course of a function, we must invoke redisplay.
>
> Not normally, no.  Normally, you select the frame and the window, and
> then redisplay will do the rest automatically after your command
> completes.  To need some change displayed in the middle of a command
> is unusual.
>

I think temporarily displaying a frame from the stack is
a useful visual technique that would see more use were it
simpler to implement.

​​
>
> ​​
> > It is the description of the interrelations of these things that
> ​​
> > is not described in a single place anywhere, especially with code
> samples,
> ​​
> > making it difficult for programmers to see what must be done.
> ​​
>
> ​​
> I don't understand why a complex task involving several steps must
> ​​
> necessarily be described in a single place.
>

​The implementation may be complex now but the user-level concept
is not.  It can be thought of as one thing: display the current
contents of a window now (regardless of the window's frame or
other frame's obscuring it or what buffer was attached at creation)
I think this seems complex to you because you know many of the
intricacies of what it takes​, but from a user perspective, it is
one thing.

​​
>
> ​​
> Once again, I suggest to add a few notes with cross-references to the
> ​​
> existing nodes; I think this should be enough for those rare cases
> ​​
> where the reader might not realize that the complete job requires
> ​​
> doing several things together.
>

​Any idea what to say?

Bob
​
​​
​​
​​