[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Pretest begins end-June
From: |
Stefan Monnier |
Subject: |
Re: Pretest begins end-June |
Date: |
Wed, 01 Jun 2011 13:45:27 -0300 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux) |
>>> (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.
Let me put the question differently:
*how* can we support code that rebinds pop-up-frames?
I think preserving backward compatibility for this case is important,
because it is used in many packages, not all of which are included in
Emacs.
> 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.
IIUC, the problems are:
1- detect that pop-up-frames was set.
2- decide whether pop-up-frames was set by user or let-bound by the caller.
3- for each of those two cases, take this request into account.
4- same for pop-up-windows.
Case 1 is easy (set the default value to `unset' and you're done).
Case 2 is more difficult. Of course, we could add a new primitive that
walks the specpdl stack to decide if a var is let-bound or not, but that
doesn't sound very appealing.
Case 3 doesn't sound too hard; IIUC it involves losing some
functionality but that functionality is absent from Emacs-23 anyway.
Do we really need to solve case 2? Probably not.
> 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 :-(
If we declare pop-up-frames and pop-up-windows as obsolete, I think it's
OK to have an heuristic simulation of its semantics as long as it
handles the known cases well enough.
Stefan
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- Re: Pretest begins end-June, Stefan Monnier, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- Re: Pretest begins end-June, Stefan Monnier, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- Re: Pretest begins end-June,
Stefan Monnier <=
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- Re: Pretest begins end-June, Stefan Monnier, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/02
- RE: Pretest begins end-June, Drew Adams, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- RE: Pretest begins end-June, Drew Adams, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/01
- Re: Pretest begins end-June, Stefan Monnier, 2011/06/01
- RE: Pretest begins end-June, Drew Adams, 2011/06/01
- Re: Pretest begins end-June, martin rudalics, 2011/06/02