Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window

[Robert Weiner <rsw@gnu.org>]

[-- Attachment #1: Type: text/plain, Size: 2987 bytes --]

On Thu, Dec 14, 2017 at 8:42 PM, Stefan Monnier <monnier@iro.umontreal.ca>
wrote:

> > Does anyone else see a need for something like this or am I the only one
> > 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.

​​
> Because the problems with focus and such don't all have to do with
> ​​
> technicalities of how the APIs work, but also with interaction about the
> ​​
> specific focus policy that the user may have chosen in his
> ​​
> window-manager (as well as with the frame/window management policies he
> ​​
> has setup in his display-buffer-alist).
> ​
>

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".

​From the Basic Concepts of Emacs Windows section of the Elisp Manual:

'In each frame, at any time, exactly one Emacs window is designated as
“selected within the frame”.  For the selected frame, that window is
called the “selected window”—the one in which most editing takes place,
and in which the cursor for selected windows appears (*note Cursor
Parameters::).  The selected window’s buffer is usually also the current
buffer, except when ‘set-buffer’ has been used (*note Current 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 gain
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 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.
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

[-- Attachment #2: Type: text/html, Size: 6169 bytes --]