[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: Fri, 19 Nov 2010 09:00:17 +0100
User-agent: Thunderbird (Windows/20090302)

> 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

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


reply via email to

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