[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: The window-pub branch

From: martin rudalics
Subject: Re: The window-pub branch
Date: Thu, 18 Nov 2010 19:48:57 +0100
User-agent: Thunderbird (Windows/20090302)

> Is it possible to have display-buffer-function back?  (Or same
> functionality with new name if you prefer.)

From the doc-string of `display-buffer-names':

   Any other symbol with a function definition means to call that
   function to display the buffer.  The function is called with two
   arguments - the buffer to display and a list of specifiers - and
   is supposed to display the buffer and return the window used for
   that purpose.  The function is also responsible for giving the
   variable `display-buffer-window' and the
   `quit-restore' parameter of the window used a meaningful value.

So why do you think it's gone?  You can define

(defun display-buffer-in-other-window-on-same-frame (buffer specifiers)
   '(same-frame (reuse-buffer-window . nil) (not-this-window . t))))

and put this into `display-buffer-names' or `display-buffer-regexps' or

(display-buffer "*scratch*" 'display-buffer-in-other-window-on-same-frame)

> Also, is it possible to route any other functions that effect to
> displaying a buffer (such as switch-to-buffer) through display-buffer
> exclusively?

With the exception of `switch-to-buffer' all these route now through
`display-buffer'.  I could add an option to have `switch-to-buffer'
route through `display-buffer' as well.  `set-window-buffer' can't be
rewritten, for obvious reasons.

> Also, is it possible to have same logic to "un-display" (hide) a
> buffer, such that delete-buffer and bury-buffer are routed through
> that, also exclusively? And then to have a hook too, such as
> "hide-buffer-function"?

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?

> And yes, that would be to bypass all the interesting logic you just
> designed and to replace it with something completely different. ;)

IIUC only your first issue fits into this remark.  The routing issue you
raised goes into the opposite direction, I presume.  And the "hiding"
logic was redesigned (confer `switch-to-prev-buffer') but it's only
loosely connected to buffer display proper.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]