emacs-devel
[Top][All Lists]
Advanced

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

Re: display-buffer cleverness - how to tame?


From: martin rudalics
Subject: Re: display-buffer cleverness - how to tame?
Date: Tue, 05 May 2009 09:02:25 +0200
User-agent: Thunderbird 2.0.0.16 (Windows/20080708)

> The question I have now is how to impose, in a particular call to
> `display-buffer', *not* splitting a window if it is not full-width? That is, 
how
> to reinstate that pre-Emacs 23 splitting criterion (temporarily)?

Emacs 22 did split a non-full-width window vertically and from your
previous posts you even relied on and wanted that behavior.  The only
new twist is that Emacs 23 may split the non-full-width largest window
even when it's not the least recently used one.

> I'd also like to know how to tell `display-buffer' not to split the selected
> window, and how to tell it specifically which window to split. Those 
approaches
> would also solve the problem I see here (in alternative ways), and that
> knowledge would be generally helpful (to me, at least).

That's what `split-window-preferred-function' is all about.  It gets
called with the window to split and you can temporarily bind your own
function to that.  That function would check if the window to split is
the selected one and, if that is the case, split another one instead
provided such a window exists.  BTW, your example is a second reason why
`split-window-preferred-function' should be called with an argument, so
I plan to leave the current calling convention alone.

>> and (2) would have failed to DTRT with
>> more than two windows on your frame or the window on the
>> right not being the least recently used one.
>
> Which is not a problem here - that cannot be the case in my context. But it is
> good to know.

If you as designer are in full control of the context then why do you
rely on `display-buffer' in the first place?  The whole idea of
`display-buffer' is to shift control to the users' customizations ...

martin





reply via email to

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