emacs-devel
[Top][All Lists]
Advanced

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

RE: Pretest begins end-June


From: Drew Adams
Subject: RE: Pretest begins end-June
Date: Wed, 1 Jun 2011 08:21:25 -0700

> Hence, if an application now wants to pop up a buffer in
> another frame it must do something like
> (pop-to-buffer buffer-or-name 'other-frame)
> instead of (let ((pop-up-frames t)) (pop-to-buffer buffer))

Which means that an app that calls another function that does (pop-to-buffer
buffer) cannot control the behavior.

What you describe is no big deal for code that calls `pop-to-buffer' directly.
But it makes it difficult if not impossible to control the behavior when code
calls other code that in turn calls `pop-to-buffer'.  Without access to changing
the latter code, one's goose is pretty much cooked.

`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 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.

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.




reply via email to

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