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: 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



reply via email to

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