[Top][All Lists]
[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: |
Thu, 02 Jun 2011 10:27:56 +0200 |
User-agent: |
Thunderbird 2.0.0.21 (Windows/20090302) |
> Which means that an app that calls another function that does (pop-to-buffer
> buffer) cannot control the behavior.
Intentionally so. Nested within that call there may be other
`display-buffer' calls of which the caller is not aware. These calls
should not be affected by any bindings. I do not have the slightest
sentiment for my `pop-up-frames' nil `debug-on-error' t setting have
(let ((pop-up-frames t))
(error "???"))
pop up a new frame.
> `pop-up-frames' is designed to be used as a dynamic ("special") var. Dynamic
> binding can be very useful, as I'm sure you know. The change you describe
works
> against that usefulness.
I suppose that `pop-up-frames' was designed as an option for the user to
control the behavior of buffer display functions. The history of this
and all related options is that of building a tower as follows:
- Initially the user was provided the option `pop-up-frames' to control
the creation of new frames.
- Applications stole the customizations by let-binding this variable to
whatever they considered appropriate.
- The user was given back the option via `special-display-popup-frame'.
- Applications stole the customizations again by binding
`special-display-buffer-names' and `special-display-regexps' to nil.
So where would you go from here?
>> I changed most of the trivial calls already but some are
>> rather special.
>
> Are you talking about just changing calls to `pop-to-buffer' in the Emacs
> sources? Many, probably most, `pop-to-buffer' calls are out there in the
wider
> Emacs world, not just in the Emacs-Dev sources.
That's why I raised this issue in my first mail.
> More importantly, what you describe apparently limits the use and usefulness
of
> `pop-up-frames' (essentially eliminating it) - it's not just about existing
> code.
>
> Please provide some way to dynamically bind _some_ var to control the
behavior.
> IOW, please restore the flexibility (control) you are apparently taking away.
That flexibility has been given back to the user.
martin
- Re: Pretest begins end-June, (continued)
- 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 <=
window-safely-shrinkable-p [was Re: Pretest begins end-June], Glenn Morris, 2011/06/11
Re: Pretest begins end-June, Eli Zaretskii, 2011/06/04
Re: Pretest begins end-June, Dan Nicolaescu, 2011/06/13