emacs-devel
[Top][All Lists]
Advanced

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

Re: Pretest begins end-June


From: martin rudalics
Subject: Re: Pretest begins end-June
Date: Wed, 01 Jun 2011 17:58:32 +0200
User-agent: Thunderbird 2.0.0.21 (Windows/20090302)

>> (let ((pop-up-frames t))
>>   (pop-to-buffer buffer))
>
> The part I don't understand is why we can't preserve backward
> compatibility for such code.

Because it's not quite easy to decide in general which value should
prevail.  When `display-buffer' encounters a setting like this it would
have to know whether it comes from a user who has set this in .emacs for
Emacs < 24 or from an application that has not yet adopted the new
behavior.

In the former case, I would have to merge the request to pop up a new
frame with the actual customization of `display-buffer-alist'.  Now
`pop-up-frames' is probably not very problematic in this context, but
the options for popping up and reusing windows have been expanded
considerably and most of these would get lost.  Note: They would get
lost because `display-buffer' would _have to assume_ that a specific
behavior was requested by the application although that application did
_not_ rebind the corresponding variable in the first place.

It might be possible to use some heuristics like "`pop-up-windows' is by
default t, so if `display-buffer' sees that this is t it will disregard
it and consult the value of `display-buffer-alist' instead".  But doing
such guesses doesn't strike me as very robust :-(

martin



reply via email to

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