[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 2.0.0.21 (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
`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
- Re: The window-pub branch, grischka, 2010/11/18
- Re: The window-pub branch, martin rudalics, 2010/11/18
- Re: The window-pub branch, grischka, 2010/11/18
- Re: The window-pub branch,
martin rudalics <=
- Re: The window-pub branch, grischka, 2010/11/19
- Re: The window-pub branch, martin rudalics, 2010/11/19
- Re: The window-pub branch, grischka, 2010/11/19
- Re: The window-pub branch, martin rudalics, 2010/11/20
- Re: The window-pub branch, grischka, 2010/11/20
- Re: The window-pub branch, martin rudalics, 2010/11/20
- Re: The window-pub branch, grischka, 2010/11/20
- Re: The window-pub branch, martin rudalics, 2010/11/21
- Re: The window-pub branch, grischka, 2010/11/21
- Re: The window-pub branch, martin rudalics, 2010/11/21