* display-buffer-reuse-frames default to t
@ 2011-01-19 16:04 Stefan Monnier
2011-01-19 16:11 ` Eli Zaretskii
` (2 more replies)
0 siblings, 3 replies; 8+ messages in thread
From: Stefan Monnier @ 2011-01-19 16:04 UTC (permalink / raw
To: emacs-devel
Any objection to defaulting display-buffer-reuse-framesto t?
Stefan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:04 display-buffer-reuse-frames default to t Stefan Monnier
@ 2011-01-19 16:11 ` Eli Zaretskii
2011-01-19 21:00 ` Stefan Monnier
2011-01-19 16:25 ` Andreas Schwab
2011-01-19 19:15 ` Tassilo Horn
2 siblings, 1 reply; 8+ messages in thread
From: Eli Zaretskii @ 2011-01-19 16:11 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
> 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)?
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:04 display-buffer-reuse-frames default to t Stefan Monnier
2011-01-19 16:11 ` Eli Zaretskii
@ 2011-01-19 16:25 ` Andreas Schwab
2011-01-19 16:44 ` martin rudalics
2011-01-19 20:59 ` Stefan Monnier
2011-01-19 19:15 ` Tassilo Horn
2 siblings, 2 replies; 8+ messages in thread
From: Andreas Schwab @ 2011-01-19 16:25 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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."
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:25 ` Andreas Schwab
@ 2011-01-19 16:44 ` martin rudalics
2011-01-19 20:59 ` Stefan Monnier
1 sibling, 0 replies; 8+ messages in thread
From: martin rudalics @ 2011-01-19 16:44 UTC (permalink / raw
To: Andreas Schwab; +Cc: Stefan Monnier, emacs-devel
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
@ 2011-01-19 18:48 MON KEY
0 siblings, 0 replies; 8+ messages in thread
From: MON KEY @ 2011-01-19 18:48 UTC (permalink / raw
To: emacs-devel
Cc: martin rudalics, Eli Zaretskii, Andreas Schwab, Stefan Monnier
>>> 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\
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:04 display-buffer-reuse-frames default to t Stefan Monnier
2011-01-19 16:11 ` Eli Zaretskii
2011-01-19 16:25 ` Andreas Schwab
@ 2011-01-19 19:15 ` Tassilo Horn
2 siblings, 0 replies; 8+ messages in thread
From: Tassilo Horn @ 2011-01-19 19:15 UTC (permalink / raw
To: Stefan Monnier; +Cc: emacs-devel
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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:25 ` Andreas Schwab
2011-01-19 16:44 ` martin rudalics
@ 2011-01-19 20:59 ` Stefan Monnier
1 sibling, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2011-01-19 20:59 UTC (permalink / raw
To: Andreas Schwab; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: display-buffer-reuse-frames default to t
2011-01-19 16:11 ` Eli Zaretskii
@ 2011-01-19 21:00 ` Stefan Monnier
0 siblings, 0 replies; 8+ messages in thread
From: Stefan Monnier @ 2011-01-19 21:00 UTC (permalink / raw
To: Eli Zaretskii; +Cc: emacs-devel
>> 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
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2011-01-19 21:00 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-01-19 16:04 display-buffer-reuse-frames default to t Stefan Monnier
2011-01-19 16:11 ` Eli Zaretskii
2011-01-19 21:00 ` Stefan Monnier
2011-01-19 16:25 ` Andreas Schwab
2011-01-19 16:44 ` martin rudalics
2011-01-19 20:59 ` Stefan Monnier
2011-01-19 19:15 ` Tassilo Horn
-- strict thread matches above, loose matches on Subject: below --
2011-01-19 18:48 MON KEY
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).