Re: managing windows in two frames

[Stefan Monnier <monnier@iro.umontreal.ca>]

> That's irrational.

Not at all.  It's a half-common need (tho most people don't realize
that other frames could be involved so they just use
save-window-excursion thinking it'll undo any damage).

> What's wrong with
> (let ((display-buffer-function 'ignore))
>   (describe-function 'ignore))

Ah, indeed it's simpler.  It does have the disadvantage of relying on an
obsolete variable, tho.

>> but it fails if the buffer ends up displayed in some other frame (or
>> worse, in a new frame), which can happen depending on the user's
>> settings.  So Jorge really wants he code to work regardless of any
>> user's customization of display-buffer, in the same sense that
>> find-file-noselect does not pay attention to the user's
>> display-buffer settings.
> If he "sits close enough" to `display-buffer', Jorge can always (1) use
> `display-buffer-function', (2) `display-buffer-overriding-action', or
> (3) bind `display-buffer-alist' to do whatever he wants.

Of course a real fix is to change the code so that it provide
a "non-displaying" variant, but Jorge often doesn't have the necessary
control over that code.  In the case of lisp--company-doc-buffer (in
lisp.el), Jorge actually does have this control but doesn't have the
energy to "do it right".

(1) uses an obsolete var.
(3) binds a user variable, which is bad karma.
(2) is good, but the question remains: "bind it to what?".  You did
provide a answer to that question, admittedly, but it's a bit
longwinded, I think we should have a simpler answer.

Maybe we should define a new macro `with-inhibit-window-changes' which
could replace save-window-excursion for those uses (it might use
save-window-excursion internally, just in case, but would also try to
prevent creation of frames and window changes in other frames).


        Stefan