RE: The window-pub branch

["Drew Adams" <drew.adams@oracle.com>]

> > > M-: (select-window (get-buffer-window "*scratch*" t))
...
> > A clear bug?  Why?
> 
> Because the doc-string of `select-window' says that "Most editing will
> apply to WINDOW's buffer" and that of `selected-window' says "The
> selected window is the window ... to which many commands apply".

And all of that is true.  But you are not using only `select-window' here.  You
are using `select-window' in the context of `M-:', that is, in the context of a
command.

Imagine if I told you that there was a bug in `select-window' just because
evaluating this sexp doesn't end up with buffer foo's window being selected:

(save-selected-window (select-window (get-buffer-window "foo")))

You would say I'm nuts: `select-window' does select foo's window, but then the
original window selection gets restored by `save-selected-window'.

M-: is like that.  `select-window' _does_ select the window in your test case.
But M-: then restores the original window selection and frame focus.

And you can see this clearly with the example I gave: just use (progn
(select-window...) (insert "TEXT")).

When you use M-: you are not just evaluating a sexp.  You are using a command
that evaluates a sexp and then restores the window selection.  If you want to
test the behavior of `select-window' then don't bring other stuff into the mix
as well.

> Moreover the modeline of the *scratch* window indicates that 
> the window is selected

Which it is.  This is just further proof of that fact.

> (which is completely disconcerting when the two frames do
> not overlap) while input goes to the other frame.

No, input does not go to the other frame.  Not during the evaluation of the sexp
given to M-:.  It is only _after_ M-: is finished that further input goes to the
window that was originally selected.

Do the text inserting in the sexp passed to M-: and you will see that it goes
where you expect.  Do the text inserting after M-: and it goes in the window
that was selected before (and after) M-:.

> The problem is within the interaction between Emacs and the window
> manager.  It does not depend on M-:.

What problem?  The fact that _after_ M-: the same window is selected as before
it?  That behavior certainly _does_ depend on M-:.

You have not shown any bug in `select-window'.  You've just gotten confused
because M-: does not only evaluate a sexp.  Take M-: out of the equation and
then try to demonstrate the supposed `select-window' bug.