bug#4748: 23.1; least recently used window - is it?

[martin rudalics <rudalics@gmx.at>]

 >> (let ((owin (selected-window)))
 >>    (dolist (window (window-list))
 >>      (unless (eq window owin)
 >>        (select-window window)))
 >>    (get-lru-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
 > question.

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 those
 > variables say not to (a la `switch-to-buffer-other-window' and `pop-to-buffer')?

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. Just
 > as a dedicated window says "don't use me", so the use-other-frame variables also
 > say "don't use me". You say that we listen to the former - but we unfortunately
 > 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 the
 > 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
window.

 > The problem is not just looking at each occurrence individually. The problem is
 > 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 all
 > means.

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 to
 > `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' to
 > 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
   `switch-to-buffer', or

- implement the `switch-to-buffer' behavior thus not respecting user
   customizations,

this won't get us anywhere.

 > And also to
 > keep the same `quit-window' behavior that you get when you use
 > `switch-to-buffer'.

Can you please describe in a few words what a "`quit-window' behavior"
is?

 >>  > 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 you
 > 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 for
 > yourself.
 >
 > 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 imagine
 > 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.

martin