all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: rswgnu@gmail.com
Cc: rudalics@gmx.at, monnier@iro.umontreal.ca, emacs-devel@gnu.org
Subject: Re: Suggestion: Add discussion of input focus handling to select-window; add select-frame-window
Date: Sat, 16 Dec 2017 20:41:12 +0200	[thread overview]
Message-ID: <83tvwqqzw7.fsf@gnu.org> (raw)
In-Reply-To: <CA+OMD9gs+rWSWAz5TS_rnM6DCNeZHNg2LMePV+rRi-DrFgg79A@mail.gmail.com> (message from Robert Weiner on Sat, 16 Dec 2017 13:16:48 -0500)

> From: Robert Weiner <rsw@gnu.org>
> Date: Sat, 16 Dec 2017 13:16:48 -0500
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, martin rudalics <rudalics@gmx.at>, 
> 	emacs-devel <emacs-devel@gnu.org>
> 
> ​When the user selects another window within the selected frame
> or a select-window is done on the selected frame, user input
> (typing) and programmatic input (insert) shifts from the prior
> window to the new window.

Correct for user input (but note the important exception of the
mini-window).  Not necessarily correct for 'insert' etc. -- many of
these APIs can work on a specified window, which is different from the
selected one.

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

> ​​Frame-level input focus is insufficient to describe the window to which
> keyboard input goes in all cases.

Keyboard input goes to the selected window of the selected frame.
Why isn't that description sufficient?

> Plus, if we want to see any changes in buffer-to-window mappings
> 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.

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

I don't understand why a complex task involving several steps must
necessarily be described in a single place.

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



  reply	other threads:[~2017-12-16 18:41 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-12-12 15:39 Suggestion: Add discussion of input focus handling to select-window; add select-frame-window Robert Weiner
2017-12-12 18:13 ` Robert Weiner
2017-12-12 18:49   ` Robert Weiner
2017-12-12 20:40   ` Stefan Monnier
2017-12-12 21:29     ` Robert Weiner
2017-12-12 21:57       ` Stefan Monnier
2017-12-12 20:37 ` Stefan Monnier
2017-12-12 21:19   ` Robert Weiner
2017-12-13  8:49 ` martin rudalics
2017-12-13 13:37   ` Stefan Monnier
2017-12-13 14:37     ` Robert Weiner
2017-12-13 19:29       ` martin rudalics
2017-12-13 20:30         ` Eli Zaretskii
2017-12-13 22:10           ` Stefan Monnier
2017-12-14  3:33             ` Eli Zaretskii
2017-12-14 15:01               ` Robert Weiner
2017-12-14 20:09                 ` Eli Zaretskii
2017-12-14 23:43                   ` Robert Weiner
2017-12-15  1:42                     ` Stefan Monnier
2017-12-16 16:11                       ` Robert Weiner
2017-12-16 16:42                         ` Eli Zaretskii
2017-12-16 17:23                           ` Robert Weiner
2017-12-16 16:27                       ` Robert Weiner
2017-12-16 16:21                 ` Robert Weiner
2017-12-16 16:29                   ` Eli Zaretskii
2017-12-16 17:04                     ` Robert Weiner
2017-12-16 17:15                       ` Robert Weiner
2017-12-16 17:26                       ` Eli Zaretskii
2017-12-16 18:16                         ` Robert Weiner
2017-12-16 18:41                           ` Eli Zaretskii [this message]
2017-12-16 19:18                             ` Robert Weiner
2017-12-16 19:56                               ` Eli Zaretskii
2017-12-16 20:52                                 ` Robert Weiner
2017-12-22 10:19                                   ` Eli Zaretskii
2017-12-16 22:44                                 ` Robert Weiner
2017-12-13 14:51   ` Robert Weiner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83tvwqqzw7.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=rswgnu@gmail.com \
    --cc=rudalics@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.