emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Weiner
Subject: Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window
Date: Sat, 16 Dec 2017 17:44:10 -0500

On Sat, Dec 16, 2017 at 2:56 PM, Eli Zaretskii <address@hidden> wrote:
> From: Robert Weiner <address@hidden>
> Date: Sat, 16 Dec 2017 14:18:09 -0500
> Cc: Stefan Monnier <address@hidden>, martin rudalics <address@hidden>,
>       emacs-devel <address@hidden>
>
>  > ​​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


reply via email to

[Prev in Thread] Current Thread [Next in Thread]