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 11:11:43 -0500 Message-ID: References: <5A30E9AF.2060105@gmx.at> <5A317FAA.3090209@gmx.at> <83d13iv095.fsf@gnu.org> <83bmj2ugok.fsf@gnu.org> <83r2rxt6jx.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113569d255f8f8056077619e" X-Trace: blaine.gmane.org 1513440746 5789 195.159.176.226 (16 Dec 2017 16:12:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 16:12:26 +0000 (UTC) Cc: martin rudalics , Eli Zaretskii , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 17:12:22 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 1eQF4W-0000yY-9b for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 17:12:21 +0100 Original-Received: from localhost ([::1]:51151 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQF4d-0003Mc-5N for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 11:12:27 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54022) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQF4W-0003Ly-6v for emacs-devel@gnu.org; Sat, 16 Dec 2017 11:12:21 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQF4R-0005j5-7P for emacs-devel@gnu.org; Sat, 16 Dec 2017 11:12:20 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:35454) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQF4R-0005iu-4f for emacs-devel@gnu.org; Sat, 16 Dec 2017 11:12:15 -0500 Original-Received: from mail-qt0-f169.google.com ([209.85.216.169]:43060) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQF4Q-0004Wo-Cd; Sat, 16 Dec 2017 11:12:14 -0500 Original-Received: by mail-qt0-f169.google.com with SMTP id w10so15516931qtb.10; Sat, 16 Dec 2017 08:12:14 -0800 (PST) X-Gm-Message-State: AKGB3mKO3mCpOTA16y0NDHVzlc37hr9p8vya2VuEHh3IbruML3kUQXdY uwwEOLRyyVKw7dWWlW/iP0K3Wl3vdP9ARLtEJMs= X-Google-Smtp-Source: ACJfBotyZELcEEnDiTI4IFHDGOhAPuRws5Lm9W6YrV1ssFMjJHQp10kANhj/J8vqYdYv2XZYOyp0YXhU5gwYe1UNmLc= X-Received: by 10.200.50.39 with SMTP id x36mr29969294qta.255.1513440733950; Sat, 16 Dec 2017 08:12:13 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 16 Dec 2017 08:11:43 -0800 (PST) In-Reply-To: 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:221130 Archived-At: --001a113569d255f8f8056077619e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Thu, Dec 14, 2017 at 8:42 PM, Stefan Monnier wrote: > > Does anyone else see a need for something like this or am I the only on= e > > that finds there are too many gotchas > > and complexities in dealing with combinations of these issues right now= ? > > I think we're generally better off embracing the idea that it's not > Emacs's job to decide how to handle focus and window stacking. > It would be nice, but my experience has been that doing so just leads to window-based commands that don't work well or properly in a multi-frame environment. =E2=80=8B=E2=80=8B > Because the problems with focus and such don't all have to do with > =E2=80=8B=E2=80=8B > technicalities of how the APIs work, but also with interaction about the > =E2=80=8B=E2=80=8B > specific focus policy that the user may have chosen in his > =E2=80=8B=E2=80=8B > window-manager (as well as with the frame/window management policies he > =E2=80=8B=E2=80=8B > has setup in his display-buffer-alist). > =E2=80=8B > Good point. But I still think the idea of selected-window could be better defined in a multi-frame environment as well as the concept of "where editing takes place". =E2=80=8BFrom the Basic Concepts of Emacs Windows section of the Elisp Manu= al: 'In each frame, at any time, exactly one Emacs window is designated as =E2=80=9Cselected within the frame=E2=80=9D. For the selected frame, that = window is called the =E2=80=9Cselected window=E2=80=9D=E2=80=94the one in which most = editing takes place, and in which the cursor for selected windows appears (*note Cursor Parameters::). The selected window=E2=80=99s buffer is usually also the cu= rrent buffer, except when =E2=80=98set-buffer=E2=80=99 has been used (*note Curre= nt Buffer::). As for non-selected frames, the window selected within the frame becomes the selected window if the frame is ever selected. *Note Selecting Windows::.' So if I programmatically select-window in a frame that does not have or gai= n input focus, will most editing take place there? Programmatic editing commands generally will and user editing commands will not. So it depends what you consider "most editing" which I think remains undefined, right? Maybe there is another as yet undefined idea in there of interactive window selection where input focus does shift. At the very least, the basic sequence of calls to select an arbitrary windo= w 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. Just as someone concerned with whether it will rain today listens to a weather report and doesn't look up the technicalities of local cloud accumulation. Yes, there are complexities here but I believe it is possible to abstract a bit more and handle basic cases better so that multi-frame window handling can be programmed more like single frame window handling for the vast majority of cases. Bob --001a113569d255f8f8056077619e Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Thu, Dec 14, 2= 017 at 8:42 PM, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
<= span>> Does anyone else see a need for something like this or am I the o= nly one
> that finds there are too many gotchas
> and complexities in dealing with combinations of these issues right no= w?

I think we're generally better off embracing the idea that it= 9;s not
Emacs's job to decide how to handle focus and window stacking.

It would be nice, but my experience has been that doing = so just
leads to window-based commands that don't work well or properl= y
in a multi-frame environment.

=E2=80=8B=E2=80=8B
Because the problems with focus and such= don't all have to do with
=E2=80=8B=E2=80=8B
technicalities of how the APIs work, but= also with interaction about the
=E2=80=8B=E2=80=8B
specific focus policy that the user may = have chosen in his
=E2=80=8B=E2=80=8B
window-manager (as well as with the fram= e/window management policies he
=E2=80=8B=E2=80=8B
has setup in his display-buffer-alist).<= div class=3D"gmail_default" style=3D"font-family:monospace,monospace;displa= y:inline">=E2=80=8B

=
Good point.=C2=A0 But I still think the idea of selected-window = could
be better defined in a multi-frame environ= ment as well as the
concept of "where editi= ng takes place".

=E2=80=8BFrom the Basic Co= ncepts of Emacs Windows section of the Elisp Manual:

'In each frame, at any time, exactly one Emacs window is= designated as
=E2=80=9Cselected within t= he frame=E2=80=9D.=C2=A0 For the selected frame, that window is
called the =E2=80=9Cselected window=E2=80=9D=E2=80= =94the one in which most editing takes place,
and in which the cursor for selected windows appears (*note Cursor
Parameters::).=C2=A0 The selected window=E2= =80=99s buffer is usually also the current
buffer, except when =E2=80=98set-buffer=E2=80=99 has been used (*note Cur= rent Buffer::).
As for non-selected frame= s, the window selected within the frame becomes
the selected window if the frame is ever selected.=C2=A0 *Note Selec= ting
Windows::.'

So if I programmatical= ly select-window in a frame that does not have or gain
input focus, will most editing take place there?=C2=A0 Progra= mmatic editing commands
generally will an= d user editing commands will not.=C2=A0 So it depends what you consider
"most editing" which I think remai= ns undefined, right?=C2=A0 Maybe there is another
as yet undefined idea in there of interactive window selection whe= re input focus
does shift.

At the very leas= t, the basic sequence of calls to select an arbitrary window
for user editing should be explained both here and in t= he 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.
Just as some= one concerned with whether it will rain today listens to a weather
report and doesn't look up the technicali= ties of local cloud accumulation.=C2=A0 Yes,
there are complexities here but I believe it is possible to abstract a = bit more and
handle basic cases better so= that multi-frame window handling can be programmed more
like single frame window handling for the vast majority of = cases.

Bob




--001a113569d255f8f8056077619e--