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 20:41:12 +0200 Message-ID: <83tvwqqzw7.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> 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 1513449694 30082 195.159.176.226 (16 Dec 2017 18:41:34 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 18:41:34 +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 19:41:27 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 1eQHOp-00070q-3V for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 19:41:27 +0100 Original-Received: from localhost ([::1]:51710 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHOt-0006Vh-9E for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 13:41:31 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33245) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHOn-0006VR-CT for emacs-devel@gnu.org; Sat, 16 Dec 2017 13:41:26 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQHOj-0001xL-Eq for emacs-devel@gnu.org; Sat, 16 Dec 2017 13:41:25 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37347) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHOj-0001x0-Au; Sat, 16 Dec 2017 13:41:21 -0500 Original-Received: from [176.228.60.248] (port=3816 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eQHOh-0008Rh-Do; Sat, 16 Dec 2017 13:41:21 -0500 In-reply-to: (message from Robert Weiner on Sat, 16 Dec 2017 13:16:48 -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:221142 Archived-At: > From: Robert Weiner > Date: Sat, 16 Dec 2017 13:16:48 -0500 > Cc: Stefan Monnier , martin rudalics , > emacs-devel > > ​When the user selects another window within the selected frame > or a select-window is done on the selected frame, user input > (typing) and programmatic input (insert) shifts from the prior > window to the new window. Correct for user input (but note the important exception of the mini-window). Not necessarily correct for 'insert' etc. -- many of these APIs can work on a specified window, which is different from the selected one. > 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. Keyboard input goes to the selected window of the selected frame. Why isn't that description sufficient? > 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. > 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. 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.