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 18:42:43 +0200 Message-ID: <83374asjy4.fsf@gnu.org> References: <5A30E9AF.2060105@gmx.at> <5A317FAA.3090209@gmx.at> <83d13iv095.fsf@gnu.org> <83bmj2ugok.fsf@gnu.org> <83r2rxt6jx.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1513442582 17659 195.159.176.226 (16 Dec 2017 16:43:02 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 16:43:02 +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 17:42:58 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 1eQFY8-0004Cf-QQ for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 17:42:56 +0100 Original-Received: from localhost ([::1]:51220 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQFYF-0000Os-SW for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 11:43:03 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60935) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQFY8-0000Oc-W6 for emacs-devel@gnu.org; Sat, 16 Dec 2017 11:42:58 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQFY4-0008ON-GA for emacs-devel@gnu.org; Sat, 16 Dec 2017 11:42:57 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35802) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQFY4-0008OC-CD; Sat, 16 Dec 2017 11:42:52 -0500 Original-Received: from [176.228.60.248] (port=3535 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eQFY2-0005Jh-FP; Sat, 16 Dec 2017 11:42:52 -0500 In-reply-to: (message from Robert Weiner on Sat, 16 Dec 2017 11:11:43 -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:221135 Archived-At: > From: Robert Weiner > Date: Sat, 16 Dec 2017 11:11:43 -0500 > Cc: Eli Zaretskii , martin rudalics , emacs-devel > > So if I programmatically select-window in a frame that does not have or gain > input focus, will most editing take place there? That's a meaningless question, IMO, because "editing takes place" means interactive editing, and that only happens _after_ your command finishes its job, and Emacs returns to the main command loop. And the manual says "_most_ editing" for a reason. > Maybe there is another as yet undefined idea in there of interactive > window selection where input focus does shift. I think you are interpreting the ELisp manual too literally. It is not meant to describe how the Emacs internals work, certainly not in all cases. The text which describes what it means for the window to be "selected" is intended to make the _notion_ of the selected window clear enough to continue describing the features which manipulate the selected window, nothing more, nothing less. You should not interpret that text as an exhaustive and mathematically rigorous _definition_ of what a selected window is, and even less when Emacs decides on its own to select a different window. The simplest example is the minibuffer window. > At the very least, the basic sequence of calls to select an arbitrary window > for user editing should be explained both here and in the select-window function, > since someone thinking about windows and buffers isn't likely to reference > frame-related documentation even though input focus is a frame-related concept. And they don't need to look up frame- and focus-related documentation, as long as they only need to select a window. What you needed is to select another frame, select another window on that frame, and make sure that frame is at the top of the z-order. That has very little to do with selecting a window, and much more to do with frames and input focus -- and those topics are described in the docs under their proper subjects. I could support some gentle notes in the ELisp manual's node "Selecting Windows", where it already mentions frames. But doc strings are inappropriate for references to almost unrelated subjects, nor for general descriptions of complex topics.