[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#4748: 23.1; least recently used window - is it?
bug#4748: 23.1; least recently used window - is it?
Mon, 19 Oct 2009 09:36:07 +0200
Thunderbird 18.104.22.168 (Windows/20090302)
>> (let ((owin (selected-window)))
>> (dolist (window (window-list))
>> (unless (eq window owin)
>> (select-window window)))
> That doesn't work either. For the same reason: `get-lru-window' will never
> return certain windows.
But it correctly sets the LRU window internally without looping.
>> ((or (window-minibuffer-p) (eq (window-dedicated-p) t))
>> (pop-to-buffer buffer-or-name nil norecord))
> (I'm curious: Why not call `pop-to-buffer' if the window is dedicated or a
> minibuffer? What's the reason for that conditional?)
Why "Why not" ... ?
> If you feel that your version of `switch-to-buffer' makes it respect the
> use-other-frame variables but otherwise have the same behavior as the current
> `switch-to-buffer', then why don't you install it?
> But do you in fact claim that? If not, I don't see it as a solution to the
My version tried to be faithful to the one written in C.
>> > `switch-to-buffer', which Stefan says repeatedly (and it
>> > sounds right to me) should not be used in Lisp code (i.e.
>> > should be used pretty much only interactively), does not
>> > respect `special-display-regexps',
>> > `special-display-buffer-names', or `pop-up-frames'.
>> Because it wouldn't make much sense to respect these ;-)
> Huh? Why not? Why shouldn't it use the current window (as now) except when
> variables say not to (a la `switch-to-buffer-other-window' and
Presently a `not-this-window' argument to `display-buffer' overrides
these variables. Any `same-window' argument would override them too.
> IOW, have it do just what you claim it already does for dedicated windows.
> as a dedicated window says "don't use me", so the use-other-frame variables
> say "don't use me". You say that we listen to the former - but we
> still do not listen to the latter.
The idea of `switch-to-buffer' is to switch to a buffer in the selected
window. This won't change ever. The only thing we can (and probably
should) change is whether an application like bookmarks does call
`switch-to-buffer' in the first place.
>> We'd have to look at each of these cases to tell whether they can use
>> `pop-to-buffer' directly.
> They cannot, by definition, if we intend to keep the current behavior of using
> the same window (except when the use-other-frame vars say not to) and having
> same `quit-window' behavior.
If using the same window is intentional (and I think in the case of
`view-buffer' this is at least discussable) it will have to use the same
> The problem is not just looking at each occurrence individually. The problem
> how to get the intended behavior (current window unless frame vars say
> otherwise; same `quit-window' behavior).
Nevertheless we have to look at each occurrence individually.
>> I can't tell. Obviously `same-window-buffer-names' and friends
>> implicitly provide the same service.
> How so? If you have a solution to the question I raised, please post it, by
By default `same-window-buffer-names' has `display-buffer' emulate the
behavior of `switch-to-buffer' for buffers like *shell* or *mail*. I
don't know whether bookmark buffers would fit that category as well.
Buffers handled by `view-buffer' certainly won't.
>> If and when we enhance `display-buffer' with a same-window argument
>> `switch-to-buffer' could become obsolete (for Elisp calls). OTOH this
>> might lead programmers to call `display-buffer' with the same-window
>> argument in these and other cases.
> Is that a discussion topic for emacs-devel? If you're proposing such a change
> `display-buffer', then it should be discussed there. Such a change shouldn't
> "just happen".
It's discussed in the "dired-pop-to-buffer in wrong place" thread.
>> Does `quit-window' behave differently wrt whether
>> `switch-to-buffer' was called or `pop-to-buffer'?
> Try it. I gave the recipe. Use the code I sent that uses `pop-to-buffer' and
> compare, using the C-x 2 C-x 3 situation, with different buffers and with the
> same buffer in all 3 windows.
What do you want me to try? Replace the `switch-to-buffer' call in
`quit-window' with `pop-to-buffer'? That would be dead wrong.
>> > The above code loops forever in some cases (e.g. C-x 2 C-x
>> > 3; put 3 diff buffers in the windows; then the small,
>> > right-hand window will never be used by
>> > `pop-to-buffer'. That is, this will not work:
>> > (cond ((one-window-p) ; This part works.
>> > (pop-to-buffer (get-buffer-create "*foo*"))
>> > (delete-other-windows))
>> > (t ; This part works except for some windows.
>> > (let ((owin (selected-window)))
>> > (while (not (eq (get-lru-window) owin))
>> > (other-window 1)))
>> > (pop-to-buffer (get-buffer-create "*foo*"))))
>> > (You'll recommend comparing with the root window, instead
>> > of calling `one-window-p', but that doesn't change the
>> > point in question.)
>> You shouldn't use `other-window' because it doesn't bury the window as
>> you expect. Loop over `window-list' instead.
> Please show me what you mean. You can see what I'm trying to do. How to do it?
I do _not_ know what you're trying. If you want to reconstruct how
`display-buffer' finds its window without using the underlying C
primitives then I can only refer you to Stefan's remark on this: You
won't be able to do that.
> And please explain why `other-window' should not be used - in what way doesn't
> it "bury the window as you expect"? Is it also a dwim function? What about
> `next-window' - would that work better?
You said you got an endless loop here. Obviously that happens because
you use `other-window'.
>> I still don't understand why and how you want to control the
>> setting of the LRU window in practice.
> I don't really care about the lru window. I was trying to get `pop-to-buffer'
> use the selected window (whatever that window is, no exceptions).
Above you wanted `pop-to-buffer' follow user customizations. Unless you
settle on either
- respect user customizations thus getting a behavior different from
- implement the `switch-to-buffer' behavior thus not respecting user
this won't get us anywhere.
> And also to
> keep the same `quit-window' behavior that you get when you use
Can you please describe in a few words what a "`quit-window' behavior"
>> > And if you have the same buffer in more than one window,
>> > then such "solutions" also behave differently from
>> > `switch-to-buffer' when you use `quit-window'. E.g.
>> > C-x 2 C-x 3, without using 3 different buffers, etc.
>> In what sense do they behave differently?
> When you quit the window, you get a different buffer from what you get when
> use `switch-to-buffer'.
... use `switch-to-buffer' _where_? In the code of `quit-window'?
> At least that's what I saw. Try the examples I mentioned
> - C-x 2 C-x 3.
Do you mean that the `other-buffer' call in `switch-to-buffer' when
called by `quit-window' chooses another buffer to display? Are you sure
you have set all NORECORD arguments correctly?
> The point is that if you use `switch-to-buffer' and then quit the window, the
> buffer that is displayed is different than what you see if you use
> `pop-to-buffer' (successfully forcing it to use the same window, at least for
> most windows) and then you quit the window. Try the examples I gave, and see
> Again, personally I don't care about preserving the same behavior that
> `switch-to-buffer' gives (wrt using the same window and quitting). But I
> that someone does, or we wouldn't still be using it.
Do you mean the examples where you call `other-window'? `other-window'
calls `select-window' which calls record_buffer so you obviously get a
completely stochastic behavior.
>> > is that such behavior is apparently a common use case.
>> > If replacing `switch-to-buffer' in, say, `view-buffer',
>> > we would presumably want to keep the same behavior as now
>> > for users who do not use `special-display-*' and `pop-up-frames'.
>> So try to experiment with the following: Have `display-buffer'
>> interpret a 'same-window value for the NOT-THIS-WINDOW argument
>> and replace calls like (switch-to-buffer buffer) with
>> (pop-to-buffer buffer 'same-window).
> I don't have any time for that, sorry.
Then I won't be able to help you at the moment.