Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window

[Robert Weiner]

On Sat, Dec 16, 2017 at 1:41 PM, Eli Zaretskii <address@hidden> 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

​

​​

​​

​​