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

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 3866 bytes --]

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

> > From: Robert Weiner <rsw@gnu.org>
> > Date: Sat, 16 Dec 2017 14:18:09 -0500
> > Cc: Stefan Monnier <monnier@iro.umontreal.ca>, martin rudalics <
> rudalics@gmx.at>,
> >       emacs-devel <emacs-devel@gnu.org>
> >
> >  > ​​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.
>
> And I disagree with that.  I think it _is_ sufficient.
>

As you said, we have covered this enough.

​
> ​​
> > ​Where is that explained?  How does one find it?
> ​​
>
> ​​
>
> ​​
> It's in the text you cited about what the "selected w
> ​​
> indow" means.  If
> ​​
> you are saying that "most editing" does not necess
> ​​
> arily cover keyboard
> ​​
> input, I'm okay with adding that as an example.
> ​​
>
​​
That would be good if it had a reference to where to find
the rest of the information covering keyboard input.

Bob
​​​​

>   (Once again, such
> text must not be interpreted too literally, because, e.g., commands
> like "C-x 5 0" are definitely "keyboard input", but affect something
> other than the selected window.)
>

​Yes.
​

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

​Okay.​

​​


> ​​
> > I think temporarily displaying a frame from the stack is
> ​​
> > a useful visual technique that would see more use were it
> ​​
> > simpler to implement.
> ​​
>
> ​​
> "Useful" does not contradict "unusual".  Because it's unusual, finding
> ​​
> the details about achieving these goals could legitimately be somewhat
> ​​
> harder than for the more popular use cases.
>

​So you are saying it may be hard yet potentially worthwhile
to do?

​​
>
> ​​
> >  ​​> 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.
> ​​
>
> ​​
> I wasn't talking about the implementation.  I was talking about the
> ​​
> task of a Lisp programmer who needs to select a window on another
> ​​
> frame and make sure the frame is raised and input focus is redirected
> ​​
> to it.  This task is more complex than just selecting a window on the
> ​​
> currently selected frame.
> ​​
>
> ​​
> > 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.
> ​​
>
> ​​
> I disagree, and not because of my developer experience, but because of
> ​​
> my user experience.
>

​So we see this differently.  Thanks for the time discussing it.

Bob

[-- Attachment #2: Type: text/html, Size: 11378 bytes --]