display-buffer-reuse-frames default to t

display-buffer-reuse-frames default to t

[Stefan Monnier]

Any objection to defaulting display-buffer-reuse-framesto t?


        Stefan

Re: display-buffer-reuse-frames default to t

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Wed, 19 Jan 2011 11:04:41 -0500
> 
> Any objection to defaulting display-buffer-reuse-framesto t?

What does it do on a tty (with more than one frame)?

Re: display-buffer-reuse-frames default to t

[Stefan Monnier]

>> Any objection to defaulting display-buffer-reuse-framesto t?
> What does it do on a tty (with more than one frame)?

Same as under X11: it will reuse a window on some other frame if it
shows the desired buffer.


        Stefan

Re: display-buffer-reuse-frames default to t

[Andreas Schwab]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Any objection to defaulting display-buffer-reuse-framesto t?

Does it restrict itself to visible frames?

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: display-buffer-reuse-frames default to t

[martin rudalics]

 >> Any objection to defaulting display-buffer-reuse-framesto t?
 >
 > Does it restrict itself to visible frames?

No.  It can use iconified frames.

Ideally, one would set this to 0, 'visible, or t and get the desired
effect.  That's what I do on my branch.

martin

Re: display-buffer-reuse-frames default to t

[Stefan Monnier]

>> Any objection to defaulting display-buffer-reuse-framesto t?
> Does it restrict itself to visible frames?

No, it restricts itself to frames on the same display (and also ignores
truly invisible frames, but not iconified frames which then get
de-iconified by display-buffer).


        Stefan

Re: display-buffer-reuse-frames default to t

[Tassilo Horn]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

Hi!

> Any objection to defaulting display-buffer-reuse-frames to t?

I used that a while ago (or the ido-variable that does the same) and was
not satisfied, because it frequently occured that the buffer to be
displayed was in an iconified frame, or on a TTY linux console frame, or
in a frame on another desktop/workspace, or, with newer KDEs, it might
be in another activity...

So as long as it cannot be guaranteed that the buffer really becomes
visible for a user, I'd vote against it.

Bye,
Tassilo

Re: display-buffer-reuse-frames default to t

[MON KEY]

>>> Any objection to defaulting display-buffer-reuse-framesto t?
>>
>> Does it restrict itself to visible frames?
>
> No.  It can use iconified frames.
>
> Ideally, one would set this to 0, 'visible, or t and get the desired
> effect.  That's what I do on my branch.

Is the suggestion to extend the range of acceptable values for
`display-buffer-reuse-frames'?

IMHO there is opportunity here for some much needed changes[1].

Indeed, it would make more sense to extend the range of values allowed
to any one of: { t nil 0 visible }

I would also suggest adding `selected-frame' as an option for
consistency with `display-buffer's provision for a "specific frame" as
argument to its FRAME parameter.

Such change would require changing the custom type declaration of
`display-buffer-reuse-frames' from:

  :type 'boolean          ;; Is the declaration even correct now?

Likewise, if such change(s) are made _please_ ensure that the
variable's docstring indicate explicitly the range of possible values
and their affect on frame/buffer display, i.e. don't just punt to
`display-buffer' with a "which see".

Maybe, better is to implement an additional/alternative variable:
 `display-buffer-reuse-frames-if-graphic'

which inherits its defaults according to `display-buffer-reuse-frames'
and `pop-up-frames'?

As it is now, the current docstring of `display-buffer-reuse-frames'
is poorly specified wrt to the interaction of `display-buffer' around
`pop-up-frames' and `display-graphic-p'. Likely many users are
left with an essentially opaque customization option which often fails
to DTRT esp. where third-party authors using `display-buffer' in an
ill adapted position to appropriately accomodate user display
customizations, cf the recent report bug 7728:

 (URL `http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7728')

and discussion of `save-window-excursion' beginning around msg 68:

 (URL `http://debbugs.gnu.org/cgi/bugreport.cgi?bug=7728#68')

[1] I use a two-head display with xrandr (and in the past with the
equivalent on w32 a three-head display) and rarely have less than two
frames open across these displays In both environments the behaviour
of `display-buffer-reuse-frames'/`display-buffer' has many weird/odd
corner cases wrt to the "strongly dedicated" and often commands do not
do what I would expect. The cummulative effect of these corner cases
is that I usually give up trying to figure out where/why/how certain
buffers/windows/frames will be displayed and just adapt to the funky.

--
/s_P\