emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Weiner
Subject: Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window
Date: Wed, 13 Dec 2017 09:51:07 -0500

On Wed, Dec 13, 2017 at 3:49 AM, martin rudalics <address@hidden> wrote:
> The doc string for select-window does not discuss the sometime need to also
> set input focus to the selected window's frame when one wants future input
> events to go there.  I would suggest adding this along with a reference to
> select-frame-set-input-focus.

`select-window' is a function with immediate effect so we can give it a
self-contained doc-string and description.

`select-frame-set-input-focus' OTOH lumps together three things: It
selects a frame and thus implicitly its selected window and tells the
window manager to raise that frame and to give it input focus.  The
latter two do not have immediate effect, they induce a delay and require
a cooperating window manager.  (Raising the frame is a bad idea IMHO but
admittedly a compromise to accommodate the standard behavior of most
existing window managers.)

So the reference you suggest would have to be accompanied by an
explanation of delays and a reference to the window manager. 

Delays and interaction with the window manager are lower-level
implementation details that could be covered in the Elisp manual
as you say, rather than the doc string.

The overriding issue is that the general concept of selecting an
editable window in most systems would include input focus going
to that window.  In Emacs, this is true in a single frame session
where selecting a window makes any following input characters go
to the window's buffer.  So new and even experienced Elisp
programmers could easily assume that selecting a window in another
frame would behave similarly.  It does not because as you note,
the situation is more complex.

So this needs to be pointed out to people when they first look at
the doc string for select-window.  Yet there is no need in the doc
string to talk about delays (any modern system will respond pretty
responsively to such requests) nor to get into window system details
other than to mention raising windows and directing input focus along
with the associated functions, as I noted in my prior message.

Bob

reply via email to

[Prev in Thread] Current Thread [Next in Thread]