bug#1061: pop-up-frames does not work on a tty

bug#1061: pop-up-frames does not work on a tty

[Dan Nicolaescu]

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.

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

[-- 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))

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

[-- 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")

bug#1061: pop-up-frames does not work on a tty

[Dan Nicolaescu]

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")

bug#1061: pop-up-frames does not work on a tty

[Dan Nicolaescu]

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")

bug#1061: pop-up-frames does not work on a tty

[Dan Nicolaescu]

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.

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

 > 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

bug#1061: pop-up-frames does not work on a tty

[Dan Nicolaescu]

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.

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

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

bug#1061: pop-up-frames does not work on a tty

[Stefan Monnier]

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

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

[-- 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);

bug#1061: pop-up-frames does not work on a tty

[Stefan Monnier]

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

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

 > 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

bug#1061: pop-up-frames does not work on a tty

[Eli Zaretskii]

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

bug#1061: pop-up-frames does not work on a tty

[Stefan Monnier]

> 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

bug#1061: pop-up-frames does not work on a tty

[Stefan Monnier]

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

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

 > 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

bug#1061: pop-up-frames does not work on a tty

[Chong Yidong]

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

bug#1061: pop-up-frames does not work on a tty

[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 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

bug#1061: pop-up-frames does not work on a tty

[martin rudalics]

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