RE: The window-pub branch

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

> So what about
> C-x 2
> M-: (select-window (next-window))

Dunno.  Maybe _that_ demonstrates a M-: bug.
Or not (below you indicate that you've found a command-loop bug).

I suggest (again) that you take M-: out of the mix while trying to figure out if
there are `select-window' or `display-buffer' or command-loop bugs.  Jumping off
to "fix" M-: is not the way to _start_.

>  >> Moreover the modeline of the *scratch* window indicates that
>  >> the window is selected
>  >
>  > Which it is.  This is just further proof of that fact.
> 
> That I'm "using a command that evaluates a sexp and then restores the
> window selection"?

No, that the *scratch* window was in fact selected.  That was the question
(remember?).  It was claimed that the window wasn't being selected, as
demonstrated by text insertion not going there.

>  > 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.
> 
> Even in the C-x 2 example?

There is no other frame in your C-x 2 example.  But yes, the `select-window'
still _does_ select the window.  Again, use (progn (select-window...) (insert
"ABC")) to see that.

Your C-x 2 example shows that M-: does not always _restore_ the window
selection.  But it does not show that `select-window' does not select the window
for insertion.

But again, I think your conversation is not about M-:.  The original M-: example
was supposed to demonstrate a bug in `select-window'.  My point was that it does
not do that.  When you use M-: you introduce additional behavior - you are not
just testing evaluation of a `select-window' sexp.

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

So I guess we are agreed on that, at least.  A bug in `select-window' should be
demonstrated without recourse to M-:.

It's quite possible that there are bugs in all of M-:, select-window, and
display-buffer, but they should be diagnosed separately.

>  > 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.
> 
> It's a bug in the command loop.  I can exhibit the same bug using
> `select-window' or `select-frame'.

Great, so you've found your answer.  After fixing that problem you can revisit
the M-: behavior to see if you still think that M-: itself needs fixing.

I'm outta here.  As I said, I don't even bind M-: to `eval-expression'
personally, so I shouldn't really care whether or not you "fix" it to become
something different.