[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 10:21:40 -0800 |
> 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.
- 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, 2010/12/07
- Re: The window-pub branch, martin rudalics, 2010/12/07
- RE: The window-pub branch,
Drew Adams <=