From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner 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 14:18:09 -0500 Message-ID: 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: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114c9586141e57056079fc8c" X-Trace: blaine.gmane.org 1513451933 30787 195.159.176.226 (16 Dec 2017 19:18:53 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 19:18:53 +0000 (UTC) Cc: martin rudalics , Stefan Monnier , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 20:18:46 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 1eQHyv-0007Oo-3h for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 20:18:45 +0100 Original-Received: from localhost ([::1]:51775 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHz2-0003PL-5v for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 14:18:52 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40805) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHyv-0003PG-98 for emacs-devel@gnu.org; Sat, 16 Dec 2017 14:18:46 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQHys-0006P6-3h for emacs-devel@gnu.org; Sat, 16 Dec 2017 14:18:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37714) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQHys-0006Ow-0L for emacs-devel@gnu.org; Sat, 16 Dec 2017 14:18:42 -0500 Original-Received: from mail-qk0-f176.google.com ([209.85.220.176]:36885) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQHyq-0001EO-Ie; Sat, 16 Dec 2017 14:18:40 -0500 Original-Received: by mail-qk0-f176.google.com with SMTP id i130so14132615qke.4; Sat, 16 Dec 2017 11:18:40 -0800 (PST) X-Gm-Message-State: AKGB3mIUyxKLKr0vC9d2oOK/ird8OzrswxlUvBCiIg5KzVzou33FB8x0 0EPuubuOCwjexLcHfvsV0YoTfATvC9gGx/rliJY= X-Google-Smtp-Source: ACJfBosTDCvMbiMgA0mFlMDPK3Q3TT+XDuw/yH7lNFofNhyEuwH3K+aH3Y05cGjMnLhQdUOltEhRKB5ZnkGMwyx8ZB8= X-Received: by 10.55.5.143 with SMTP id 137mr23900537qkf.231.1513451920037; Sat, 16 Dec 2017 11:18:40 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 16 Dec 2017 11:18:09 -0800 (PST) In-Reply-To: <83tvwqqzw7.fsf@gnu.org> X-Gmail-Original-Message-ID: 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:221145 Archived-At: --001a114c9586141e57056079fc8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 16, 2017 at 1:41 PM, Eli Zaretskii wrote: > > > 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. > > > =E2=80=8B=E2=80=8BFrame-level input focus is insufficient to describe t= he window to which > > keyboard input goes in all cases. > =E2=80=8BWe 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. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Keyboard input goes to the selected window of the selected frame. > =E2=80=8B=E2=80=8B > Why isn't that description sufficient? > =E2=80=8BWhere is that explained? How does one find it? =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > Plus, if we want to see any changes in buffer-to-window mappings > =E2=80=8B=E2=80=8B > > 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. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > It is the description of the interrelations of these things that > =E2=80=8B=E2=80=8B > > is not described in a single place anywhere, especially with code > samples, > =E2=80=8B=E2=80=8B > > making it difficult for programmers to see what must be done. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I don't understand why a complex task involving several steps must > =E2=80=8B=E2=80=8B > necessarily be described in a single place. > =E2=80=8BThe implementation may be complex now but the user-level concept is not. It can be thought of as one thing: display the current contents of a window now (regardless of the window's frame or other frame's obscuring it or what buffer was attached at creation) I think this seems complex to you because you know many of the intricacies of what it takes=E2=80=8B, but from a user perspective, it is one thing. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Once again, I suggest to add a few notes with cross-references to the > =E2=80=8B=E2=80=8B > existing nodes; I think this should be enough for those rare cases > =E2=80=8B=E2=80=8B > where the reader might not realize that the complete job requires > =E2=80=8B=E2=80=8B > doing several things together. > =E2=80=8BAny idea what to say? Bob =E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B =E2=80=8B=E2=80=8B --001a114c9586141e57056079fc8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 16, 2= 017 at 1:41 PM, Eli Zaretskii <el= iz@gnu.org> wrot= e:

> 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 nee= d
only select the window.

> =E2=80=8B=E2=80=8BFrame-level input focus is insufficient to describe = the window to which
> keyboard input goes in all cases.

= =E2=80=8BWe were talking about how input focus was an insufficient
concept= to describe which window user input is directed to.
Similarly, select-win= dow is insufficient by itself as well.
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Keyboard input goes to the select= ed window of the selected frame.
=E2=80=8B=E2=80=8B
Why isn't that description sufficien= t?

=E2=80=8BWhere is that explained?=C2=A0 How d= oes one find it?
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> Plus, if we want to see any changes= in buffer-to-window mappings
=E2=80=8B=E2=80=8B
> during the course of a function, we= must invoke redisplay.

Not normally, no.=C2=A0 Normally, you select the frame and the windo= w, and
then redisplay will do the rest automatically after your command
completes.=C2=A0 To need some change displayed in the middle of a command is unusual.

I think temporarily displaying a fra= me from the stack is
a useful visual technique that would see more use wer= e it
simpler to implement.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> It is the description of the interr= elations of these things that
=E2=80=8B=E2=80=8B
> is not described in a single place = anywhere, especially with code samples,
=E2=80=8B=E2=80=8B
> making it difficult for programmers= to see what must be done.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I don't understand why a comp= lex task involving several steps must
=E2=80=8B=E2=80=8B
necessarily be described in a single pla= ce.

=E2=80=8BThe implementation may be complex n= ow but the user-level concept
is not.=C2=A0 It can be thought of as one th= ing: display the current
contents of a window now (regardless of the windo= w's frame or
other frame's obscuring it or what buffer was attache= d at creation)
I think this seems complex to you because you know many of = the
intricacies of what it takes=E2=80=8B, but from a user perspective, it= is
one thing.

=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Once again, I suggest to add a few notes= with cross-references to the
=E2=80=8B=E2=80=8B
existing nodes; I think this should be e= nough for those rare cases
=E2=80=8B=E2=80=8B
where the reader might not realize that = the complete job requires
=E2=80=8B=E2=80=8B
doing several things together.

=E2=80=8BAny idea what to say?

Bob
=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

--001a114c9586141e57056079fc8c--