* bug#1061: pop-up-frames does not work on a tty
@ 2008-10-01 8:40 Dan Nicolaescu
2008-10-01 13:05 ` martin rudalics
2008-10-01 13:26 ` martin rudalics
0 siblings, 2 replies; 20+ messages in thread
From: Dan Nicolaescu @ 2008-10-01 8:40 UTC (permalink / raw)
To: bug-gnu-emacs
With the current CVS HEAD:
emacs -Q -nw
M-: (setq pop-up-frames t) RET
C-h f ding RET
The *Help* buffer does not appear at this point, a new frame is created,
but the current frame does not show the help buffer.
with emacs-22.2 the *Help* buffer is displayed.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 8:40 Dan Nicolaescu
@ 2008-10-01 13:05 ` martin rudalics
2008-10-01 15:57 ` Dan Nicolaescu
2008-10-01 13:26 ` martin rudalics
1 sibling, 1 reply; 20+ messages in thread
From: martin rudalics @ 2008-10-01 13:05 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1061
[-- Attachment #1: Type: text/plain, Size: 585 bytes --]
> With the current CVS HEAD:
>
> emacs -Q -nw
> M-: (setq pop-up-frames t) RET
> C-h f ding RET
>
> The *Help* buffer does not appear at this point, a new frame is created,
> but the current frame does not show the help buffer.
I'm aware of this problem. Does the attached patch fix it?
> with emacs-22.2 the *Help* buffer is displayed.
Not here on Windows. And I wonder how this could work on your system.
FWIW, the underlying logic did not change.
Does `pop-to-buffer' for some arbitrary, non-visible buffer work with
-nw? What happens with `display-buffer'?
martin
[-- Attachment #2: 1061.diff --]
[-- Type: text/plain, Size: 959 bytes --]
*** window.el.~1.153.~ 2008-09-13 10:14:15.250000000 +0200
--- window.el 2008-10-01 14:51:12.437500000 +0200
***************
*** 987,994 ****
buffer (if (listp pars) pars))))))
((or pop-up-frames (not frame-to-use))
;; We want or need a new frame.
! (window--display-buffer-2
! buffer (frame-selected-window (funcall pop-up-frame-function))))
((and pop-up-windows
;; Make a new window.
(or (not (frame-parameter frame-to-use 'unsplittable))
--- 987,997 ----
buffer (if (listp pars) pars))))))
((or pop-up-frames (not frame-to-use))
;; We want or need a new frame.
! (setq frame-to-use (funcall pop-up-frame-function))
! (prog1
! (window--display-buffer-2
! buffer (frame-selected-window frame-to-use))
! (select-frame-set-input-focus frame-to-use)))
((and pop-up-windows
;; Make a new window.
(or (not (frame-parameter frame-to-use 'unsplittable))
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 8:40 Dan Nicolaescu
2008-10-01 13:05 ` martin rudalics
@ 2008-10-01 13:26 ` martin rudalics
2008-10-01 15:20 ` Dan Nicolaescu
2008-10-01 15:20 ` Dan Nicolaescu
1 sibling, 2 replies; 20+ messages in thread
From: martin rudalics @ 2008-10-01 13:26 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1061
[-- Attachment #1: Type: text/plain, Size: 83 bytes --]
The previous patch was probably too drastic. Let's try
the attached one.
martin
[-- Attachment #2: 1061.diff --]
[-- Type: text/plain, Size: 808 bytes --]
*** help.el.~1.342.~ 2008-08-14 07:46:20.718750000 +0200
--- help.el 2008-10-01 15:19:23.250000000 +0200
***************
*** 1056,1062 ****
"Type \"q\" to quit") window))
((= number-of-windows 1)
;; The help window is alone on a frame and not the selected
! ;; window, could be the `pop-up-frames' t case.
(help-window-display-message
(cond
(keep-frame "Type \"q\" to delete this window")
--- 1056,1063 ----
"Type \"q\" to quit") window))
((= number-of-windows 1)
;; The help window is alone on a frame and not the selected
! ;; window, probably the `pop-up-frames' t case.
! (select-frame-set-input-focus (window-frame window))
(help-window-display-message
(cond
(keep-frame "Type \"q\" to delete this window")
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 13:26 ` martin rudalics
@ 2008-10-01 15:20 ` Dan Nicolaescu
2008-10-01 15:20 ` Dan Nicolaescu
1 sibling, 0 replies; 20+ messages in thread
From: Dan Nicolaescu @ 2008-10-01 15:20 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061
martin rudalics <rudalics@gmx.at> writes:
> The previous patch was probably too drastic. Let's try
> the attached one.
Thanks.
This might fix the *Help* case, but other function are not
working either:
C-x C-b
M-x grep
> martin
>
> *** help.el.~1.342.~ 2008-08-14 07:46:20.718750000 +0200
> --- help.el 2008-10-01 15:19:23.250000000 +0200
> ***************
> *** 1056,1062 ****
> "Type \"q\" to quit") window))
> ((= number-of-windows 1)
> ;; The help window is alone on a frame and not the selected
> ! ;; window, could be the `pop-up-frames' t case.
> (help-window-display-message
> (cond
> (keep-frame "Type \"q\" to delete this window")
> --- 1056,1063 ----
> "Type \"q\" to quit") window))
> ((= number-of-windows 1)
> ;; The help window is alone on a frame and not the selected
> ! ;; window, probably the `pop-up-frames' t case.
> ! (select-frame-set-input-focus (window-frame window))
> (help-window-display-message
> (cond
> (keep-frame "Type \"q\" to delete this window")
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 13:26 ` martin rudalics
2008-10-01 15:20 ` Dan Nicolaescu
@ 2008-10-01 15:20 ` Dan Nicolaescu
2008-10-01 18:20 ` martin rudalics
1 sibling, 1 reply; 20+ messages in thread
From: Dan Nicolaescu @ 2008-10-01 15:20 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061
martin rudalics <rudalics@gmx.at> writes:
> The previous patch was probably too drastic. Let's try
> the attached one.
Thanks.
This might fix the *Help* case, but other functions are not
working either:
C-x C-b
M-x grep
> martin
>
> *** help.el.~1.342.~ 2008-08-14 07:46:20.718750000 +0200
> --- help.el 2008-10-01 15:19:23.250000000 +0200
> ***************
> *** 1056,1062 ****
> "Type \"q\" to quit") window))
> ((= number-of-windows 1)
> ;; The help window is alone on a frame and not the selected
> ! ;; window, could be the `pop-up-frames' t case.
> (help-window-display-message
> (cond
> (keep-frame "Type \"q\" to delete this window")
> --- 1056,1063 ----
> "Type \"q\" to quit") window))
> ((= number-of-windows 1)
> ;; The help window is alone on a frame and not the selected
> ! ;; window, probably the `pop-up-frames' t case.
> ! (select-frame-set-input-focus (window-frame window))
> (help-window-display-message
> (cond
> (keep-frame "Type \"q\" to delete this window")
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 13:05 ` martin rudalics
@ 2008-10-01 15:57 ` Dan Nicolaescu
0 siblings, 0 replies; 20+ messages in thread
From: Dan Nicolaescu @ 2008-10-01 15:57 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061
martin rudalics <rudalics@gmx.at> writes:
> > with emacs-22.2 the *Help* buffer is displayed.
>
> Not here on Windows. And I wonder how this could work on your system.
> FWIW, the underlying logic did not change.
Hmm, it does not work for me either, I probably had a typo in the
variable name when evaluating the `setq' on emacs-22.2... Sorry for the
false alarm.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 15:20 ` Dan Nicolaescu
@ 2008-10-01 18:20 ` martin rudalics
2008-10-01 18:56 ` Dan Nicolaescu
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2008-10-01 18:20 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1061
> This might fix the *Help* case, but other functions are not
> working either:
> C-x C-b
`list-buffers' should use `pop-to-buffer' in the first place.
> M-x grep
Sorry, I don't understand how this is supposed to work.
You can observe similar behavior with emacs -Q and `pop-up-frames'
non-nil: Type C-h C-h b and watch Emacs iconify the *Help* buffer.
Often `display-buffer' seem to DTRT because most window managers
automatically raise a new frame behind Emacs' back. Hence working on a
tty seems one of the rare cases where the fact that `display-buffer'
does not raise a frame really bites.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 18:20 ` martin rudalics
@ 2008-10-01 18:56 ` Dan Nicolaescu
2008-10-02 9:33 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Dan Nicolaescu @ 2008-10-01 18:56 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061
martin rudalics <rudalics@gmx.at> writes:
> > M-x grep
>
> Sorry, I don't understand how this is supposed to work.
Show the *grep* buffer?
I run into these when I was asked to test the --daemon patch with
pop-to-frames, I personally don't know much about pop-to-frames. I
thought these things worked in emacs-22, but that turned out not to be
the case. Maybe nobody cares about this stuff anyway, in which case
closing the bug seems appropriate.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-01 18:56 ` Dan Nicolaescu
@ 2008-10-02 9:33 ` martin rudalics
2008-10-02 12:45 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2008-10-02 9:33 UTC (permalink / raw)
To: Dan Nicolaescu; +Cc: 1061
> > > M-x grep
> >
> > Sorry, I don't understand how this is supposed to work.
>
> Show the *grep* buffer?
What I meant is that `grep' uses `compilation-start' which uses
`display-buffer' and I don't understand how this is supposed to show the
buffer on ttys. Juri Linkov noted
http://lists.gnu.org/archive/html/emacs-devel/2007-11/msg01832.html
but I'm not sure whether the subsequent fix has done any good or harm.
> I run into these when I was asked to test the --daemon patch with
> pop-to-frames, I personally don't know much about pop-to-frames.
pop-"up"-frames I presume.
> I
> thought these things worked in emacs-22, but that turned out not to be
> the case. Maybe nobody cares about this stuff anyway, in which case
> closing the bug seems appropriate.
`display-buffer' with `pop-up-frames' was and is broken on ttys: Take
`display-warning' or `display-buffer-other-frame'. `select-frame' based
commands like `info-lookup' are broken on graphical _and_ text-only
terminals.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-02 9:33 ` martin rudalics
@ 2008-10-02 12:45 ` Stefan Monnier
2008-10-03 11:51 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2008-10-02 12:45 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061, Dan Nicolaescu
> `display-buffer' with `pop-up-frames' was and is broken on ttys: Take
> `display-warning' or `display-buffer-other-frame'.
Yes, the more I think of it, the more I feel like pop-up-frames) should
be ignored on ttys (and maybe special-display-buffers as well).
Stefan
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-02 12:45 ` Stefan Monnier
@ 2008-10-03 11:51 ` martin rudalics
2008-10-03 13:09 ` Stefan Monnier
0 siblings, 1 reply; 20+ messages in thread
From: martin rudalics @ 2008-10-03 11:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1061, Dan Nicolaescu
[-- Attachment #1: Type: text/plain, Size: 275 bytes --]
> Yes, the more I think of it, the more I feel like pop-up-frames) should
> be ignored on ttys (and maybe special-display-buffers as well).
Why throw out the child with the bathwater? We could have `raise-frame'
simply select its argument on text-only terminals.
martin
[-- Attachment #2: 1061.diff --]
[-- Type: text/plain, Size: 1408 bytes --]
*** frame.c.~1.394.~ 2008-09-30 19:36:42.968750000 +0200
--- frame.c 2008-10-03 13:47:18.171875000 +0200
***************
*** 2004,2010 ****
If FRAME is invisible or iconified, make it visible.
If you don't specify a frame, the selected frame is used.
If Emacs is displaying on an ordinary terminal or some other device which
! doesn't support multiple overlapping frames, this function does nothing. */)
(frame)
Lisp_Object frame;
{
--- 2004,2010 ----
If FRAME is invisible or iconified, make it visible.
If you don't specify a frame, the selected frame is used.
If Emacs is displaying on an ordinary terminal or some other device which
! doesn't support multiple overlapping frames, this function selects FRAME. */)
(frame)
Lisp_Object frame;
{
***************
*** 2016,2023 ****
f = XFRAME (frame);
! /* Do like the documentation says. */
! Fmake_frame_visible (frame);
if (FRAME_TERMINAL (f)->frame_raise_lower_hook)
(*FRAME_TERMINAL (f)->frame_raise_lower_hook) (f, 1);
--- 2016,2027 ----
f = XFRAME (frame);
! if (FRAME_TERMCAP_P (f))
! /* On a text-only terminal select FRAME. */
! Fselect_frame (frame);
! else
! /* Do like the documentation says. */
! Fmake_frame_visible (frame);
if (FRAME_TERMINAL (f)->frame_raise_lower_hook)
(*FRAME_TERMINAL (f)->frame_raise_lower_hook) (f, 1);
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-03 11:51 ` martin rudalics
@ 2008-10-03 13:09 ` Stefan Monnier
2008-10-03 13:41 ` martin rudalics
2008-10-03 17:06 ` Eli Zaretskii
0 siblings, 2 replies; 20+ messages in thread
From: Stefan Monnier @ 2008-10-03 13:09 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061, Dan Nicolaescu
>> Yes, the more I think of it, the more I feel like pop-up-frames) should
>> be ignored on ttys (and maybe special-display-buffers as well).
> Why throw out the child with the bathwater?
I love pop-up-frames, but I only set it in X11 sessions. Now with
multi-tty I often find myself doing M-: (setq pop-up-frames nil) RET
because my tty sessions (within X11 sessions) are simply unbearable.
> We could have `raise-frame' simply select its argument on
> text-only terminals.
Not good enough. The support for frames under ttys is not sufficiently
good for that: there are *very* few ways for the user to manage his
frames and go from one to another. Also under ttys, having many
different frames all showing a single buffer in a single window is
pretty dumb: you may as well use a single frame with a single window and
switch buffers in there. Yet, pop-up-frames tends to put you in
such situations. I think that under a tty, frames only really make
sense when the user sets them up explicitly, not implicitly as part of
calls to display-buffer.
Stefan
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-03 13:09 ` Stefan Monnier
@ 2008-10-03 13:41 ` martin rudalics
2008-10-06 14:02 ` Stefan Monnier
2008-10-03 17:06 ` Eli Zaretskii
1 sibling, 1 reply; 20+ messages in thread
From: martin rudalics @ 2008-10-03 13:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1061, Dan Nicolaescu
> Not good enough. The support for frames under ttys is not sufficiently
> good for that: there are *very* few ways for the user to manage his
> frames and go from one to another. Also under ttys, having many
> different frames all showing a single buffer in a single window is
> pretty dumb: you may as well use a single frame with a single window and
> switch buffers in there. Yet, pop-up-frames tends to put you in
> such situations. I think that under a tty, frames only really make
> sense when the user sets them up explicitly, not implicitly as part of
> calls to display-buffer.
OK. But `display-buffer' and `raise-frame' seem _both_ broken on a tty.
Fixing the former won't fix the latter.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-03 13:09 ` Stefan Monnier
2008-10-03 13:41 ` martin rudalics
@ 2008-10-03 17:06 ` Eli Zaretskii
2008-10-06 14:06 ` Stefan Monnier
1 sibling, 1 reply; 20+ messages in thread
From: Eli Zaretskii @ 2008-10-03 17:06 UTC (permalink / raw)
To: Stefan Monnier, 1061; +Cc: bug-gnu-emacs
> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Fri, 03 Oct 2008 09:09:17 -0400
> Cc: 1061@emacsbugs.donarmstrong.com, Dan Nicolaescu <dann@ics.uci.edu>
>
> The support for frames under ttys is not sufficiently good for that:
> there are *very* few ways for the user to manage his frames and go
> from one to another.
What's wrong with select-frame-by-name?
> I think that under a tty, frames only really make sense when the
> user sets them up explicitly, not implicitly as part of calls to
> display-buffer.
As someone who uses frames a lot on a tty, I agree. Usually, each
my frame is set to do some specific set of related activities. For
example, I'd typically have a frame for reading mail, another one for
whatever current programming project I'm busy with, yet another for
reading Info manuals, etc. The names of the frames would be set
accordingly: "Mail", "Prog", "Docs", etc. select-frame-by-name comes
very handy to switch between frames with mnemonic frame names.
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-03 13:41 ` martin rudalics
@ 2008-10-06 14:02 ` Stefan Monnier
2008-10-06 16:31 ` martin rudalics
0 siblings, 1 reply; 20+ messages in thread
From: Stefan Monnier @ 2008-10-06 14:02 UTC (permalink / raw)
To: martin rudalics; +Cc: 1061, Dan Nicolaescu
> OK. But `display-buffer' and `raise-frame' seem _both_ broken on a tty.
> Fixing the former won't fix the latter.
Yes, indeed. And fixing raise-frame won't fix display-buffer.
Stefan
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-03 17:06 ` Eli Zaretskii
@ 2008-10-06 14:06 ` Stefan Monnier
0 siblings, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2008-10-06 14:06 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 1061, bug-gnu-emacs
>> The support for frames under ttys is not sufficiently good for that:
>> there are *very* few ways for the user to manage his frames and go
>> from one to another.
> What's wrong with select-frame-by-name?
That and C-x 5 o are the only ways I know. 2 is "very few".
And if you use pop-up-frames, you'll see that select-frame-by-name is
not good enough, because the names are chosen automatically for you and
you get name clashes, etc...
>> I think that under a tty, frames only really make sense when the
>> user sets them up explicitly, not implicitly as part of calls to
>> display-buffer.
> As someone who uses frames a lot on a tty, I agree. Usually, each
> my frame is set to do some specific set of related activities. For
> example, I'd typically have a frame for reading mail, another one for
> whatever current programming project I'm busy with, yet another for
> reading Info manuals, etc. The names of the frames would be set
> accordingly: "Mail", "Prog", "Docs", etc. select-frame-by-name comes
> very handy to switch between frames with mnemonic frame names.
Exactly: this use was the intended one, and it works well for that case,
but pop-up-frames is a whole other game.
Stefan
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-06 14:02 ` Stefan Monnier
@ 2008-10-06 16:31 ` martin rudalics
0 siblings, 0 replies; 20+ messages in thread
From: martin rudalics @ 2008-10-06 16:31 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1061, Dan Nicolaescu
> Yes, indeed. And fixing raise-frame won't fix display-buffer.
Not in your sense, I know.
It will fix `display-buffer-reuse-frames' though.
martin
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
@ 2008-10-09 0:51 Chong Yidong
2008-10-09 1:59 ` Stefan Monnier
2008-10-09 8:33 ` martin rudalics
0 siblings, 2 replies; 20+ messages in thread
From: Chong Yidong @ 2008-10-09 0:51 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 1061, Dan Nicolaescu
It may not be wise to change the behavior of pop-up-frames so radically
right now. How bout the following change, which allows a
`on-graphic-displays' value of pop-up-frames to restrict pop-up-frames
to graphic displays?
Martin's patch can go on top of this, for those people who do want to
use pop-up-frames on ttys (who knows, frame manipulation on ttys might
improve in the future).
diff -c /home/cyd/trunk/lisp/window.el.\~1.154.\~ /home/cyd/trunk/lisp/window.el
*** trunk/lisp/window.el.~1.154.~ 2008-10-05 14:13:01.000000000 -0400
--- trunk/lisp/window.el 2008-10-08 20:46:19.000000000 -0400
***************
*** 710,717 ****
:group 'windows)
(defcustom pop-up-frames nil
! "Non-nil means `display-buffer' should make a separate frame."
! :type 'boolean
:group 'windows)
(defcustom display-buffer-reuse-frames nil
--- 710,723 ----
:group 'windows)
(defcustom pop-up-frames nil
! "Whether `display-buffer' should make a separate frame.
! If nil, never make a seperate frame.
! If the value is `on-graphic-displays', make a separate frame only
! if the selected frame is on a graphic display.
! Any other non-nil value means to make a separate frame."
! :type '(choice (const :tag "Never" nil)
! (const :tag "On graphic displays" on-graphic-displays)
! (const :tag "Always" t))
:group 'windows)
(defcustom display-buffer-reuse-frames nil
***************
*** 941,946 ****
--- 947,957 ----
(not (or not-this-window
(window-dedicated-p (selected-window))
(window-minibuffer-p))))
+ (use-pop-up-frame
+ (cond ((null pop-up-frames) nil)
+ ((eq pop-up-frames 'on-graphic-displays)
+ (display-graphic-p))
+ (t t)))
(buffer (if (bufferp buffer-or-name)
buffer-or-name
(get-buffer buffer-or-name)))
***************
*** 967,973 ****
;; If the buffer's name tells us to use the selected window do so.
(window--display-buffer-2 buffer (selected-window)))
((let ((frames (or frame
! (and (or pop-up-frames display-buffer-reuse-frames
(not (last-nonminibuffer-frame)))
0)
(last-nonminibuffer-frame))))
--- 978,985 ----
;; If the buffer's name tells us to use the selected window do so.
(window--display-buffer-2 buffer (selected-window)))
((let ((frames (or frame
! (and (or use-pop-up-frame
! display-buffer-reuse-frames
(not (last-nonminibuffer-frame)))
0)
(last-nonminibuffer-frame))))
***************
*** 983,989 ****
(when pars
(funcall special-display-function
buffer (if (listp pars) pars))))))
! ((or pop-up-frames (not frame-to-use))
;; We want or need a new frame.
(window--display-buffer-2
buffer (frame-selected-window (funcall pop-up-frame-function))))
--- 995,1001 ----
(when pars
(funcall special-display-function
buffer (if (listp pars) pars))))))
! ((or use-pop-up-frame (not frame-to-use))
;; We want or need a new frame.
(window--display-buffer-2
buffer (frame-selected-window (funcall pop-up-frame-function))))
Diff finished. Wed Oct 8 20:46:21 2008
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-09 0:51 bug#1061: pop-up-frames does not work on a tty Chong Yidong
@ 2008-10-09 1:59 ` Stefan Monnier
2008-10-09 8:33 ` martin rudalics
1 sibling, 0 replies; 20+ messages in thread
From: Stefan Monnier @ 2008-10-09 1:59 UTC (permalink / raw)
To: Chong Yidong; +Cc: 1061, Dan Nicolaescu
> It may not be wise to change the behavior of pop-up-frames so radically
> right now. How bout the following change, which allows a
> `on-graphic-displays' value of pop-up-frames to restrict pop-up-frames
> to graphic displays?
I was thinking of using a `tty' value to say "even on ttys" (which would
have changed the behavior for t along the lines of what I suggest), but
your suggestion is OK as well.
Stefan
^ permalink raw reply [flat|nested] 20+ messages in thread
* bug#1061: pop-up-frames does not work on a tty
2008-10-09 0:51 bug#1061: pop-up-frames does not work on a tty Chong Yidong
2008-10-09 1:59 ` Stefan Monnier
@ 2008-10-09 8:33 ` martin rudalics
1 sibling, 0 replies; 20+ messages in thread
From: martin rudalics @ 2008-10-09 8:33 UTC (permalink / raw)
To: Chong Yidong; +Cc: 1061, Dan Nicolaescu, Stefan Monnier
> It may not be wise to change the behavior of pop-up-frames so radically
> right now. How bout the following change, which allows a
> `on-graphic-displays' value of pop-up-frames to restrict pop-up-frames
> to graphic displays?
I checked in a slightly modified version.
Thanks for coming to an agreement on this, martin.
^ permalink raw reply [flat|nested] 20+ messages in thread
end of thread, other threads:[~2008-10-09 8:33 UTC | newest]
Thread overview: 20+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-10-09 0:51 bug#1061: pop-up-frames does not work on a tty Chong Yidong
2008-10-09 1:59 ` Stefan Monnier
2008-10-09 8:33 ` martin rudalics
-- strict thread matches above, loose matches on Subject: below --
2008-10-01 8:40 Dan Nicolaescu
2008-10-01 13:05 ` martin rudalics
2008-10-01 15:57 ` Dan Nicolaescu
2008-10-01 13:26 ` martin rudalics
2008-10-01 15:20 ` Dan Nicolaescu
2008-10-01 15:20 ` Dan Nicolaescu
2008-10-01 18:20 ` martin rudalics
2008-10-01 18:56 ` Dan Nicolaescu
2008-10-02 9:33 ` martin rudalics
2008-10-02 12:45 ` Stefan Monnier
2008-10-03 11:51 ` martin rudalics
2008-10-03 13:09 ` Stefan Monnier
2008-10-03 13:41 ` martin rudalics
2008-10-06 14:02 ` Stefan Monnier
2008-10-06 16:31 ` martin rudalics
2008-10-03 17:06 ` Eli Zaretskii
2008-10-06 14:06 ` Stefan Monnier
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).