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

[martin rudalics]

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