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

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

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

[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

[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

[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

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

>> 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: marked as done (pop-up-frames does not work on a tty)

[Emacs bug Tracking System]

[-- Attachment #1: Type: text/plain, Size: 841 bytes --]


Your message dated Thu, 09 Oct 2008 10:33:54 +0200
with message-id <48EDC1F2.4050305@gmx.at>
and subject line Re: bug#1061: pop-up-frames does not work on a tty
has caused the Emacs bug report #1061,
regarding pop-up-frames does not work on a tty
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact don@donarmstrong.com
immediately.)


-- 
1061: http://emacsbugs.donarmstrong.com/cgi-bin/bugreport.cgi?bug=1061
Emacs Bug Tracking System
Contact don@donarmstrong.com with problems

[-- Attachment #2: Type: message/rfc822, Size: 2603 bytes --]

From: Dan Nicolaescu <dann@ics.uci.edu>
To: bug-gnu-emacs@gnu.org
Subject: pop-up-frames does not work on a tty
Date: Wed, 1 Oct 2008 01:40:23 -0700 (PDT)
Message-ID: <200810010840.m918eNXF002502@mothra.ics.uci.edu>


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.




[-- Attachment #3: Type: message/rfc822, Size: 1661 bytes --]

From: martin rudalics <rudalics@gmx.at>
To: 1061-done@emacsbugs.donarmstrong.com
Subject: Re: bug#1061: pop-up-frames does not work on a tty
Date: Thu, 09 Oct 2008 10:33:54 +0200
Message-ID: <48EDC1F2.4050305@gmx.at>

Fixed as

	* window.el (pop-up-frames): Add choice graphic-only.
	(display-buffer): When pop-up-frames equals graphic-only do
	not pop up new frame on text-only terminals.  (Bug#1061)

	* frame.c (Fraise_frame): On text-only terminals select frame in
	order to make it visible.  (Bug#1061)

martin