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: Eli Zaretskii
Subject: Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window
Date: Sat, 16 Dec 2017 21:56:48 +0200

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

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

It's in the text you cited about what the "selected window" means.  If
you are saying that "most editing" does not necessarily cover keyboard
input, I'm okay with adding that as an example.  (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.)

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

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

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

But at this point in the dispute, let's agree to disagree, because
we've reiterated the same arguments at least thrice.

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

I thought you might have an idea, but if not, I will do it.



reply via email to

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