Re: The window-pub branch

[martin rudalics <rudalics@gmx.at>]

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

Moreover the modeline of the *scratch* window indicates that the window
is selected (which is completely disconcerting when the two frames do
not overlap) while input goes to the other frame.

Admittedly, the doc-string of `select-frame' says that "If you are using
a window system, the previously selected frame may be restored as the
selected frame when returning to the command loop, because it still may
have the window system's input focus.".  But I cannot give a frame input
focus every time I select a window.  Hence I have to rely on the command
loop to tell the window manager that the selected window's frame should
get focus.

Due to this behavior `display-buffer', when popping up a new frame, has
to select that frame although by design it should not change the
selected window.  Also, due to this bug `display-buffer-other-frame'
never worked as Richard intended.

 > Yes, Lisp evaluation can have side effects, but AFAIK this behavior for `M-:'
 > was intentional.  `M-:' was meant to evaluate a sexp in a one-off operation, but
 > keep the input focus etc. where it was.  I think it has behaved this way since
 > Day One, and the behavior makes sense, to me at least.
 >
 > IMO this has nothing to do with your surrounding window discussion; this part is
 > only about the interactive behavior of command `eval-expression'.
 >
 > (But I admit that I don't even use `eval-expression' for `M-:' - I use
 > `pp-eval-expression' instead (or something similar) for `M-:'.)

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

martin