From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel 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 Message-ID: <83po7eqwe7.fsf@gnu.org> References: <5A30E9AF.2060105@gmx.at> <5A317FAA.3090209@gmx.at> <83d13iv095.fsf@gnu.org> <83bmj2ugok.fsf@gnu.org> <834loqskkw.fsf@gnu.org> <83wp1mr3cp.fsf@gnu.org> <83tvwqqzw7.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1513455075 8390 195.159.176.226 (16 Dec 2017 20:11:15 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 20:11:15 +0000 (UTC) Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: rswgnu@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 21:11:10 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQIn8-0000e4-Sp for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 21:10:39 +0100 Original-Received: from localhost ([::1]:51865 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQIa2-0002El-CU for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 14:57:06 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47956) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQIZv-0002ED-RS for emacs-devel@gnu.org; Sat, 16 Dec 2017 14:57:01 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQIZs-0001qW-OI for emacs-devel@gnu.org; Sat, 16 Dec 2017 14:56:59 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:38289) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQIZs-0001q8-Kd; Sat, 16 Dec 2017 14:56:56 -0500 Original-Received: from [176.228.60.248] (port=3837 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eQIZq-0002lV-NP; Sat, 16 Dec 2017 14:56:56 -0500 In-reply-to: (message from Robert Weiner on Sat, 16 Dec 2017 14:18:09 -0500) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221149 Archived-At: > From: Robert Weiner > Date: Sat, 16 Dec 2017 14:18:09 -0500 > Cc: Stefan Monnier , martin rudalics , > emacs-devel > > > ​​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.