[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: The window-pub branch
From: |
Drew Adams |
Subject: |
RE: The window-pub branch |
Date: |
Tue, 7 Dec 2010 09:43:27 -0800 |
> > > 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.
- Re: The window-pub branch, (continued)
- Re: The window-pub branch, grischka, 2010/12/07
- Re: The window-pub branch, martin rudalics, 2010/12/07
- RE: The window-pub branch, Drew Adams, 2010/12/07
- Re: The window-pub branch, grischka, 2010/12/07
- RE: The window-pub branch, Drew Adams, 2010/12/07
- Re: The window-pub branch, martin rudalics, 2010/12/07
- RE: The window-pub branch,
Drew Adams <=
- Re: The window-pub branch, martin rudalics, 2010/12/07
- RE: The window-pub branch, Drew Adams, 2010/12/07