[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The window-pub branch

From: grischka
Subject: Re: The window-pub branch
Date: Tue, 07 Dec 2010 17:38:26 +0100
User-agent: Thunderbird (Windows/20090812)

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

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

reply via email to

[Prev in Thread] Current Thread [Next in Thread]