[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
frames dedicated to buffers, or, always see specific buffers in a specif
From: |
João Távora |
Subject: |
frames dedicated to buffers, or, always see specific buffers in a specific frame |
Date: |
Sun, 14 Apr 2013 19:42:23 +0100 |
>> yes, you understand correctly.
>
> So for making this general purpose you should use `pop-to-buffer'
> instead of `display-buffer'.
Yes, that works too. Why exactly is this more general purpose?
>> control how `display-buffer' but not
>
> ... only, I presume ...
Sorry I mean "a lot of control over how it gets called, but not when
it gets called"
>> when it is called. The advice is because I
>> want ibuffer and ido to work with this as well.
>
> These should refrain from using `switch-to-buffer(-...)' and use
> `pop-to-buffer' with the `display-buffer-same-window' directive instead.
> Wherever this bothers you, file a bug report so it gets fixed.
it didn't bother me until now, let's see if I use this frequently...
Also, ido has these `ido-default-buffer-method' and
`ido-default-file-method' that can be set to various options to
control how buffer appears.
But the way these options implemented does not bring them all to
`display-buffer', which sometimes precludes user's control. Should't
they be implemented via `display-buffer-alist', keeping any of the
user's entries on top?
> [...] Couldn't you use some more human predicate for this purpose?
Yes, I could of course, but was too lazy. I could use any
buffer-checking predicate. There could be some kind of var
`joaot/browse-buffer-predicates' tried in order by
`joaot/browse-buffer-p'.
>
> This was the intention of `display-buffer-alist' and IIRC at some time I
> had already removed all calls of `switch-to-buffer' from the Emacs code
> base. Somehow this got reverted later.
Pity. But what about making `switch-to-buffer' delegate to
`display-buffer' too? It could dinamically bind `display-buffer-alist'
to display and select the buffer, but keeping any existing entries
(probably set by the user, or other programs) on top.
If that resulted in `switch-to-buffer' not switching to the buffer's
window, it could not be considered unexpected behaviour, since
ultimately the user set `display-buffer-alist' himself.
> `switch-to-buffer' is the traditional means to interactively show a
> buffer in the selected window. It shouldn't be used in Lisp code.
Yes I see. But see above for a (possibly naive) fix.
> This doesn't sound right. When `display-buffer' has found a window it
> should stop right there. Anything else would constitute a bug. If you
> can reproduce it, step through it with the debugger to find out what
> goes wrong.
My fault, sorry. The function displaying the buffer must return a
window object, anything else results in funny behaviour.
Anyway, it's working nicely now, thanks for the help.
--
João Távora