Re: The window-pub branch

[martin rudalics <rudalics@gmx.at>]

 > I don't want display "*scratch*".  I want
 >    (setq display-buffer-regexps '(((".*") my-display-buffer)))
 > ;-)

So do that.  But beware of calling `display-buffer' in it.  (I think
I'll have to restore the old `display-buffer-function' as well.)

 > One exception is still an exception.  Why do you need it?

Because `switch-to-buffer' is special.  If you want `display-buffer'
behavior use `display-buffer-same-window'.  I intend to replace all
`switch-to-buffer' calls from Elisp by that.

 > Also, what method does your code use to display "*compilation*"?
 > It doesn't seem to like my-display-buffer.

Try setting the `override' specifier ;-)

 >> `set-window-buffer' can't be rewritten, for obvious reasons.
 >
 > Why not? You could rename the current low-level one to
 > "set-window-buffer-internal".

`set-window-buffer' _is_ low-level.  Emacs needs some mechanism to
bypass whatever people do in `my-display-buffer'.

 >> Hiding a buffer is done by `replace-buffer-in-windows' which is called
 >> by `kill-buffer' (I suppose you mean that by "delete-buffer").  I don't
 >> understand the semantics of `bury-buffer' well enough.  What would you
 >> want to put on that hook?
 >
 > Obviously some code to replace a buffer in its window(s) rsp. delete
 > the window(s).

There's no single entry point for "hiding a buffer".  The nearest
equivalent is probably `switch-to-prev-buffer'.  But sometimes the
window gets deleted before and in the worst case *scratch* must be
recreated to show some buffer in the window.

Note that `display-buffer' and a hypothetical `undisplay-buffer' would
not be not orthogonal.  It's hardly possible to tell whether a buffer
shown in a window was effectively put there by `display-buffer' or by
`set-window-buffer'.

 >> IIUC only your first issue fits into this remark.  The routing issue you
 >> raised goes into the opposite direction, I presume.
 >
 > No, same direction.  Obviously only what is routed through the same
 > function can be catched by a single hook in that function.

I see what you mean.

 >> And the "hiding"
 >> logic was redesigned (confer `switch-to-prev-buffer') but it's only
 >> loosely connected to buffer display proper.
 >
 > IMO strongly symmetrically related.

But difficult to detect in practice.

 > So, is it possible to hook 'switch-to-prev-buffer' in order to catch
 > buffer "undisplay", with no exception?

No.  `set-window-buffer' can do such an "undisplay" and I see no way to
catch that.  (You can hook into `window-configuration-change-hook' but
that wouldn't help you much: At the time it gets called the buffer was
already unhidden.)

 > Also, while we're at it: I think I want hooks for "select-window",
 > "set-window-buffer" and finally "split-window", too.

The latter two call `window-configuration-change-hook'.  The easiest
thing would be to call that for `select-window' too.  The problem is
that all these hooks don't provide much information about the window
configuration before the split, selection, ...

martin