Re: The window-pub branch

[grischka <grishka@gmx.de>]

Drew Adams wrote:
>>> Open a second frame, show *scratch*, go to the first frame, show
>>> some file, type M-: (select-window (get-buffer-window "*scratch*" t))
>>> type some more chars.
>>>
>>> For me, chars go to file (GTK and MS-Windows).
>> A clear bug IMHO.  The command loop must switch focus here.
> 
> A clear bug?  Why?  It all depends what the intention (design) of `M-:' is.  It
> sounds like you are trying to redesign it.
> 
> 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.

Then what about
     M-: (display-buffer "*scratch*" nil t)
which does indeed select the window on the other frame and switch focus.

While it is documented as
     (display-buffer BUFFER-OR-NAME &optional NOT-THIS-WINDOW FRAME)
     Make buffer BUFFER-OR-NAME appear in some window but !!! don't select !!! it.

Whereas 'select-window'
     (select-window WINDOW &optional NORECORD)
     Select WINDOW.  Most editing will apply to WINDOW's buffer.

does NOT select the window to apply my editing.

What are the intentions you see and how do they make sense to you?
Just curious ...

> 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-:'.)