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

[martin rudalics <rudalics@gmx.at>]

 > The name, and the description overall (especially up to that point), seem to
 > suggest that the function speaks for the notion: it returns the window that is
 > actually least recently used. The reader is thus misled (at least up to that
 > point).

Maybe.  I'll leave this to people more literate.

 >> I suppose it's for historical reasons.  `get-lru-window'
 >> should provide a window useful for displaying a buffer.
 >> On older displays full-width windows were probably more useful.
 >
 > So rename it
 > `get-the-window-Emacs-cleverly-thinks-is-the-most-useful-to-display' or
 > something, and deprecate the name that is misleading.

The behavior was introduced nearly 25 years ago by this change

1985-09-07  Richard M. Stallman  (rms@mit-prep)

	...
	* window.c (Fget_lru_window):
	Give preference to full-width windows.

so I think we should leave that alone.

 > Same problem for function `get-largest-window'. The behavior is such that you do
 > not necessarily get the largest window. (Yes, I know, that's documented.)

Where do you see a difference in the documentation of `get-lru-window'?

 >>  > What I would really like to be able to is to _set_ the
 >>  > least recently used window - however Emacs wants to define that.
 >>
 >> You can do that by temporarily selecting all other windows ...
 >
 > Tell me how, please.
 >
 > Consider this, for instance. You might think that it would cause the selected
 > window (`owin') to become the lru window, and then to be used by `pop-to-buffer'
 > for its display.
 >
 > (let ((owin  (selected-window)))
 >   (while (not (eq (get-lru-window) owin))
 >    (other-window 1)))
 >
 > And that works . . . except for some windows, in which case it loops forever.
 > IOW, there are apparently some windows that are never lru (in the sense of
 > `get-lru-window').

Well, we know that there are such windows.

 > So please tell me how to do it (e.g. "by temporarily selecting all other
 > windows").

Something like

(let ((owin (selected-window)))
   (dolist (window (window-list))
     (unless (eq window owin)
       (select-window window)))
   (get-lru-window))

 > Which means you cannot use `pop-up-buffer' in any reasonable way to get the
 > window-selection behavior of `switch-to-buffer'. Or else please show me how.

Maybe.  My `switch-to-buffer' is in Elisp for quite some time.  It goes
like

(defun switch-to-buffer (buffer-or-name &optional norecord)
   "Switch to buffer BUFFER-OR-NAME in the selected window.
If BUFFER-OR-NAME does not identify an existing buffer, then this
function creates a buffer with that name.

When called from Lisp, BUFFER-OR-NAME may be a buffer, a string
\(a buffer name), or nil.  If BUFFER-OR-NAME is nil, then this
function chooses a buffer using `other-buffer'.  Optional second
arg NORECORD non-nil means do not put this buffer at the front of
the list of recently selected ones.  This function returns the
buffer it switched to.

WARNING: This is NOT the way to work on another buffer
temporarily within a Lisp program!  Use `set-buffer' instead.
That avoids messing with the window-buffer correspondences."
   (interactive "BSwitch to buffer:\nP")
   (cond
    ((eq buffer-or-name (window-buffer))
     ;; Basically a NOP.  Avoid signalling an error in the case where
     ;; the selected window is dedicated, or a minibuffer.

     ;; But do put this buffer at the front of the buffer list, unless
     ;; that has been inhibited.  Note that even if BUFFER is at the
     ;; front of the main buffer-list already, we still want to move it
     ;; to the front of the frame's buffer list.
     (unless norecord
       (record-buffer buffer-or-name)
       (set-buffer buffer-or-name)))
    ((or (window-minibuffer-p) (eq (window-dedicated-p) t))
     (pop-to-buffer buffer-or-name nil norecord))
    (t
     (let (buffer)
       (if buffer-or-name
	  (progn
	    (setq buffer (get-buffer buffer-or-name))
	    (unless buffer
	      (setq buffer (get-buffer-create buffer-or-name))
	      (set-buffer-major-mode buffer)))
	(setq buffer (other-buffer (current-buffer))))
       (set-buffer buffer)
       (unless norecord
	(record-buffer buffer))
       (set-window-buffer nil buffer)
       buffer))))

but you can't try that on your system because you don't have
`record-buffer' (you could comment out the call though).

 > `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 ;-)

 > And yet `switch-to-buffer' _is_ used in Lisp code, including in the Emacs
 > sources. It is called from commonly used commands, such as `bookmark-bmenu-list'
 > and `view-buffer'/`view-file' (which means, e.g., `view-emacs-news').

We'd have to look at each of these cases to tell whether they can use
`pop-to-buffer' directly.

 > Presumably, there is a common use case there that should be respected: someone
 > wants to substitute for the current buffer preferably in the same window,
 > instead of opening a new window and moving focus there. Dunno if that's a
 > reasonable use case - I never need that behavior myself, but it seems to be
 > fairly common.

I can't tell.  Obviously `same-window-buffer-names' and friends
implicitly provide the same service.

 > Assuming we should be able to meet that use case, what's the right replacement
 > for `switch-to-buffer' for that case?

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.

 > What code will do the same thing wrt which
 > window gets used and which buffer will be put in place after using, say,
 > `quit-window' in the newly displayed buffer?

Does `quit-window' behave differently wrt whether `switch-to-buffer' was
called or `pop-to-buffer'?

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

 > Here's another attempt, which at least doesn't loop forever: Replace the `let'
 > sexp above by this:
 >
 > (dotimes (i (1- (count-windows))) (other-window 1))
 >
 > That suffers from more or less the same problem: the newly displayed buffer is
 > never shown in the right-hand window - the full-width window is always used
 > whenever the right-hand window is selected. (But of course this preference for
 > full-width is inconsistent - the just-as-small left-hand window _is_ used to
 > display the buffer. IOW, this dwim does not dwim.)
 >
 > [You cannot just use (other-window (1- (count-window)) instead of a loop,
 > because that doesn't cycle the window-selection (lru) order.]

I still don't understand why and how you want to control the setting of
the LRU window in practice.

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

 > 1. The reason for avoiding `switch-to-buffer' here, and using `pop-to-buffer'
 > instead, is so that variables such as `special-display-*' and `pop-up-frames'
 > will be respected. E.g., if `special-display-regexps' is ("[ ]?[*][^*]+[*]"),
 > then *foo* will be opened in its own, special frame.

Good.

 > 2. The reason for trying to simulate `switch-to-buffer's which-window-gets-used
 > behavior and its `quit-window' behavior

I still don't understand - what is `switch-to-buffer's `quit-window'
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).

 > Again, dunno about #2. Maybe we should just forget about that use case and
 > replace `switch-to-buffer' willy nilly by `pop-to-buffer'/`display-buffer'?
 >
 > Or maybe we should redefine `switch-to-buffer' so that it respects the variables
 > in question (and possibly other relevant variables, if any). IOW, make it use
 > `display-buffer'. (Why doesn't it?)

It does (if the selected window is dedicated).

 > And perhaps add a parameter to `display-buffer' to let you use the same window
 > or specify the window to use?

See above.

 > Or perhaps allow you to more easily set the least
 > recently used window and specify that the full-width stuff be ignored?

I wouldn't object that.

 > Or (more likely) maybe I'm missing something, and there is already a reasonable
 > way to get both (a) the `switch-to-buffer' behavior wrt window selection and
 > `quit-window' and (b) the `display-buffer' behavior wrt the use-another-frame
 > variables?
 >
 > In which case, please enlighten me. How should we replace `switch-to-buffer' in,
 > say, `view-buffer' or `bookmark-bmenu-list' (or...)?

First you have to enlighten me wrt the quit-window behavior.

 >>  > Currently, it doesn't seem easy to predict or control
 >>  > which window is used by things such as `pop-to-buffer'
 >>  > that try to use another window. Being able to set the
 >>  > so-called lruw that such functions use would
 >>  > make things a lot more straightforward.
 >>
 >> We can easily remove the FULL-WIDTH feature.  But _who_ would be
 >> responsible for "touching" windows in order to make them LRU?
 >
 > I would do it in my code - if it worked.

But it's the _user_ who should touch the windows, not the application
programmer.

 > But the main question is posed above. Given the aim of, in effect, making
 > `pop-to-buffer' use a particular window, I tried to somehow set a window to be
 > the lru. But that doesn't work because of the full-width criterion.
 >
 > When there is no substitute for a clever, behind-the-scenes dwim behavior, users
 > (including Elisp users) lose control. Even if the under-cover magic DTRT 99% of
 > the time (which is not certain), there should be some reasonable way for
 > programmers to control the behavior (get beyond the dwim).
 >
 > I was hoping that simply making a window be the least recently used one would
 > cause `pop-to-buffer' to use that window. But things are apparently far from so
 > simple. I'm hoping you or someone else (e.g. Stefan) has a simple solution that
 > I've been blind to.

Stefan has proposed to enhance the NOT-THIS-WINDOW argument of
`display-buffer' for this purpose and I'm all for it.

martin