display-buffer

display-buffer

[Nick Roberts]

The doc string for display-buffer says:

"Make buffer appear in some window but don't select it...."

If I force a new frame by setting pop-up-frames to t or using
special-display-regexps then this window *is* selected.

Is that a bug?

Can I do something so the selected window is unchanged?

Nick

RE: display-buffer

[Drew Adams]

    The doc string for display-buffer says: "Make buffer appear
    in some window but don't select it...."

    If I force a new frame by setting pop-up-frames to t or using
    special-display-regexps then this window *is* selected.
    Is that a bug? Can I do something so the selected window is unchanged?

Are you on Windows?  That's what I see too, on Windows.  See the thread "Q
on frame focus with MS Windows" from 10/25-26.

It seems that the Windows window-manager automatically focusses a new frame
when it is created.  However, display-buffer also seems to focus an
_existing_  frame to display its buffer. I don't know if the latter part is
an Emacs bug or, again, a Windows window-manager problem.  As I said on
10/25:

    It seems that the problem is not just with newly created
    frames (which is why I do the select-frame-set-input-focus
    even when no new frame is created).  In spite of the doc string
    for display-buffer, on MS Windows display-buffer always sends
    the focus to the displayed buffer.

As far as a workaround is concerned, I haven't found a good solution.  I do
hacks like save the existing frame, display the buffer, then call
select-frame-set-input-focus on the original frame.

It would be great if Emacs itself could deal with this, so users didn't have
to.

Re: display-buffer

[Stefan Monnier]

> As far as a workaround is concerned, I haven't found a good solution.  I do
> hacks like save the existing frame, display the buffer, then call
> select-frame-set-input-focus on the original frame.

What about the patch I'd suggested (see below)?
Does it do any good?


        Stefan


--- window.c	03 nov 2005 12:10:51 -0500	1.525
+++ window.c	03 nov 2005 12:10:23 -0500	
@@ -3473,7 +3473,13 @@
      we need to create a new frame.  */
   if (pop_up_frames || last_nonminibuf_frame == 0)
     {
+      Lisp_Object w = Fselected_window ();
+      struct gcpro gcpro1;
+      GCPRO1 (w);
       window = Fframe_selected_window (call0 (Vpop_up_frame_function));
+      if (Fwindow_live_p (w))
+	Fselect_window (w, Qt);
+      UNGCPRO;
       Fset_window_buffer (window, buffer, Qnil);
       return display_buffer_1 (window);
     }

RE: display-buffer

[Drew Adams]

    > As far as a workaround is concerned, I haven't found a good
    > solution.  I do
    > hacks like save the existing frame, display the buffer, then call
    > select-frame-set-input-focus on the original frame.

    What about the patch I'd suggested (see below)?
    Does it do any good?

I can't build Emacs from source code here, but I believe (hope) that it was
(being) tested by someone a few months back - I never heard any more on
that.  If it works, and it makes it into Emacs, that will be great (thanks).

Re: display-buffer

[Nick Roberts]

 > > As far as a workaround is concerned, I haven't found a good solution.  I do
 > > hacks like save the existing frame, display the buffer, then call
 > > select-frame-set-input-focus on the original frame.
 > 
 > What about the patch I'd suggested (see below)?
 > Does it do any good?

What behaviour does this change?

I see:

A new frame takes focus and its window selected.
An existing frame doesn't take focus, raises and its window is not selected.

I see now that the frame with focus must have the selected-window, so its
probablt a frame manager issue, but the above behaviour is the same without
your patch.

Nick

Re: display-buffer

[Stefan Monnier]

>> What about the patch I'd suggested (see below)?
>> Does it do any good?

> What behaviour does this change?

> I see:

> A new frame takes focus and its window selected.
> An existing frame doesn't take focus, raises and its window is not selected.

This is with my patch?  Is it any different from the behavior without
my patch?


        Stefan

Re: display-buffer

[Nick Roberts]

Stefan Monnier writes:
 > >> What about the patch I'd suggested (see below)?
 > >> Does it do any good?
 > 
 > > What behaviour does this change?
 > 
 > > I see:
 > 
 > > A new frame takes focus and its window selected.
 > > An existing frame doesn't take focus, raises and its window is not selected.
 > 
 > This is with my patch?  Is it any different from the behavior without
 > my patch?

No its the same or at least I can't any difference.  My window manager is
metacity and it works/is configured for click-to-focus (not a lisp variable?)
However focus-follows-mouse is t, but I guess Emacs can't overrule the window
manager.

I guess generally that I would prefer the new frame not to take focus with
display-buffer (but perhaps not always).  Is that possible (perhaps as an
argument or user option)?

Nick

Re: display-buffer

[Luc Teirlinck]

Nick Roberts wrote:

   No its the same or at least I can't any difference.  My window
   manager is metacity and it works/is configured for click-to-focus
   (not a lisp variable?)  However focus-follows-mouse is t, but I
   guess Emacs can't overrule the window manager.

I have not been following this thread.  But unless I misunderstand the
above, your window manager is configured for click-to-focus and you
have focus-follows-mouse set to t.  If so, you are unavoidably going to
experience some buggish feeling behavior.  The purpose of
`focus-follows-mouse' is to inform Emacs how your window manager
behaves.  Its purpose is not to have Emacs try to overrule your window
manager.  If I understood you correctly, you should set
focus-follows-mouse set to nil.

C-h v focus-follows-mouse:

*Non-nil if window system changes focus when you move the mouse.
You should set this variable to tell Emacs how your window manager
handles focus, since there is no way in general for Emacs to find out
automatically.

Sincerely,

Luc.

Re: display-buffer

[Nick Roberts]

 >    No its the same or at least I can't any difference.  My window
 >    manager is metacity and it works/is configured for click-to-focus
 >    (not a lisp variable?)  However focus-follows-mouse is t, but I
 >    guess Emacs can't overrule the window manager.
 > 
 > I have not been following this thread.  But unless I misunderstand the
 > above, your window manager is configured for click-to-focus and you
 > have focus-follows-mouse set to t.  If so, you are unavoidably going to
 > experience some buggish feeling behavior.  The purpose of
 > `focus-follows-mouse' is to inform Emacs how your window manager
 > behaves.  Its purpose is not to have Emacs try to overrule your window
 > manager.  If I understood you correctly, you should set
 > focus-follows-mouse set to nil.

I can't see any difference in behaviour when focus-follows-mouse is t or nil.
If I configure metacity so that focus follows mouse, then display-buffer and
other lisp commands seem to behave as before, although clearly focus now
changes if I move the mouse from one Emacs frame to another.

Nick

Re: display-buffer

[Richard M. Stallman]

    If I force a new frame by setting pop-up-frames to t or using
    special-display-regexps then this window *is* selected.

Is it _always_ selected?
Do you use click-to-focus or focus-follows-mouse?

    Is that a bug?

If you use focus-follows-mouse, and the new frame
pops up where the mouse is, then I think this is
imevitable.  Otherwise, I think it is a bug.

RE: display-buffer

[Drew Adams]

I'll answer too, in case that helps.

        If I force a new frame by setting pop-up-frames to
        t or using special-display-regexps then this window
        *is* selected.

    Is it _always_ selected?

Yes, I believe so - each time display-buffer is called.

emacs -q
(setq pop-up-frames t)
(display-buffer "*scratch*") ; new frame - "normal" for Windows

Click in original frame, to focus it.
(display-buffer "*scratch*") ; reuses existing frame, but focusses it

    Do you use click-to-focus or focus-follows-mouse?

The Windows window manager is only click-to-focus, I believe. I don't know
of a way to change that.  IIUC, that means that focus-follows-mouse doesn't
do anything (and that is what I observe).

        Is that a bug?

    If you use focus-follows-mouse, and the new frame
    pops up where the mouse is, then I think this is
    imevitable.  Otherwise, I think it is a bug.

Re: display-buffer

[Stefan Monnier]

> The Windows window manager is only click-to-focus, I believe.

It's not.

> I don't know of a way to change that.

There's a utilisty called PowerUI or something that lets you configure
things to be focus-follows-mouse.


        Stefan

Re: display-buffer

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Date: Thu, 03 Nov 2005 23:21:15 -0500
> Cc: Nick Roberts <nickrob@snap.net.nz>, rms@gnu.org, emacs-devel@gnu.org
> 
> > The Windows window manager is only click-to-focus, I believe.
> 
> It's not.
> 
> > I don't know of a way to change that.
> 
> There's a utilisty called PowerUI or something

Close.  It's TweakUI from PowerToys.

> that lets you configure things to be focus-follows-mouse.

Yes.  I turn that on in every Windows box I use, because I cannot
stand the default Windows focus policy.

Re: display-buffer

[Richard M. Stallman]

    > The Windows window manager is only click-to-focus, I believe.

    It's not.

That's a tangent, not related to the current bug.

click-to-focus is a legitimate mode of operation, and Emacs ought to
DTRT when used in that mode.  The bug just reported is that Emacs does
the wrong thing when used on Windows in click-to-focus mode.  So
people who maintain Emacs for Windows might want to investigate.

Re: display-buffer

[Richard M. Stallman]

    Yes, I believe so - each time display-buffer is called.

    emacs -q
    (setq pop-up-frames t)
    (display-buffer "*scratch*") ; new frame - "normal" for Windows

    Click in original frame, to focus it.
    (display-buffer "*scratch*") ; reuses existing frame, but focusses it

    The Windows window manager is only click-to-focus, I believe. I don't know
    of a way to change that.

In that case, I agree it is a bug.
If it is a Windows-specific bug, people who work on Windows
will look at it, I guess.

display-buffer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

The doc string of `display-buffer' says:

    If ACTION is non-nil, it should have the form (FUNCTION . ALIST),
    where FUNCTION is either a function or a list of functions, and
    ALIST is an arbitrary association list (alist).

    Each such FUNCTION should accept two arguments: the buffer to
    display and an alist.  Based on those arguments, it should
    display the buffer and return the window.

I think FUNCTION is allowed to do nothing and return nil.
The doc string should say so.

It should also say that ACTION can have only FUNCTIONs
or only an ALIST.

-- 
Dr Richard Stallman
President, Free Software Foundation
51 Franklin St
Boston MA 02110
USA
www.fsf.org  www.gnu.org
Skype: No way! That's nonfree (freedom-denying) software.
  Use Ekiga or an ordinary phone call.