all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* display-buffer
@ 2005-11-03  0:25 Nick Roberts
  2005-11-03 16:09 ` display-buffer Drew Adams
  2005-11-03 21:40 ` display-buffer Richard M. Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Nick Roberts @ 2005-11-03  0:25 UTC (permalink / raw)



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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: display-buffer
  2005-11-03  0:25 display-buffer Nick Roberts
@ 2005-11-03 16:09 ` Drew Adams
  2005-11-03 17:18   ` display-buffer Stefan Monnier
  2005-11-03 21:40 ` display-buffer Richard M. Stallman
  1 sibling, 1 reply; 16+ messages in thread
From: Drew Adams @ 2005-11-03 16:09 UTC (permalink / raw)


    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03 16:09 ` display-buffer Drew Adams
@ 2005-11-03 17:18   ` Stefan Monnier
  2005-11-03 19:32     ` display-buffer Drew Adams
  2005-11-03 21:43     ` display-buffer Nick Roberts
  0 siblings, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2005-11-03 17:18 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: display-buffer
  2005-11-03 17:18   ` display-buffer Stefan Monnier
@ 2005-11-03 19:32     ` Drew Adams
  2005-11-03 21:43     ` display-buffer Nick Roberts
  1 sibling, 0 replies; 16+ messages in thread
From: Drew Adams @ 2005-11-03 19:32 UTC (permalink / raw)


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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03  0:25 display-buffer Nick Roberts
  2005-11-03 16:09 ` display-buffer Drew Adams
@ 2005-11-03 21:40 ` Richard M. Stallman
  2005-11-03 21:49   ` display-buffer Drew Adams
  1 sibling, 1 reply; 16+ messages in thread
From: Richard M. Stallman @ 2005-11-03 21:40 UTC (permalink / raw)
  Cc: emacs-devel

    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03 17:18   ` display-buffer Stefan Monnier
  2005-11-03 19:32     ` display-buffer Drew Adams
@ 2005-11-03 21:43     ` Nick Roberts
  2005-11-04  4:23       ` display-buffer Stefan Monnier
  1 sibling, 1 reply; 16+ messages in thread
From: Nick Roberts @ 2005-11-03 21:43 UTC (permalink / raw)
  Cc: Drew Adams, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* RE: display-buffer
  2005-11-03 21:40 ` display-buffer Richard M. Stallman
@ 2005-11-03 21:49   ` Drew Adams
  2005-11-04  4:21     ` display-buffer Stefan Monnier
  2005-11-05  1:37     ` display-buffer Richard M. Stallman
  0 siblings, 2 replies; 16+ messages in thread
From: Drew Adams @ 2005-11-03 21:49 UTC (permalink / raw)
  Cc: emacs-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03 21:49   ` display-buffer Drew Adams
@ 2005-11-04  4:21     ` Stefan Monnier
  2005-11-04 10:45       ` display-buffer Eli Zaretskii
  2005-11-05  1:36       ` display-buffer Richard M. Stallman
  2005-11-05  1:37     ` display-buffer Richard M. Stallman
  1 sibling, 2 replies; 16+ messages in thread
From: Stefan Monnier @ 2005-11-04  4:21 UTC (permalink / raw)
  Cc: Nick Roberts, rms, emacs-devel

> 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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03 21:43     ` display-buffer Nick Roberts
@ 2005-11-04  4:23       ` Stefan Monnier
  2005-11-05  5:05         ` display-buffer Nick Roberts
  0 siblings, 1 reply; 16+ messages in thread
From: Stefan Monnier @ 2005-11-04  4:23 UTC (permalink / raw)
  Cc: Drew Adams, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-04  4:21     ` display-buffer Stefan Monnier
@ 2005-11-04 10:45       ` Eli Zaretskii
  2005-11-05  1:36       ` display-buffer Richard M. Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Eli Zaretskii @ 2005-11-04 10:45 UTC (permalink / raw)
  Cc: emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-04  4:21     ` display-buffer Stefan Monnier
  2005-11-04 10:45       ` display-buffer Eli Zaretskii
@ 2005-11-05  1:36       ` Richard M. Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard M. Stallman @ 2005-11-05  1:36 UTC (permalink / raw)
  Cc: nickrob, drew.adams, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-03 21:49   ` display-buffer Drew Adams
  2005-11-04  4:21     ` display-buffer Stefan Monnier
@ 2005-11-05  1:37     ` Richard M. Stallman
  1 sibling, 0 replies; 16+ messages in thread
From: Richard M. Stallman @ 2005-11-05  1:37 UTC (permalink / raw)
  Cc: nickrob, emacs-devel

    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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-04  4:23       ` display-buffer Stefan Monnier
@ 2005-11-05  5:05         ` Nick Roberts
  2005-11-05  5:19           ` display-buffer Luc Teirlinck
  0 siblings, 1 reply; 16+ messages in thread
From: Nick Roberts @ 2005-11-05  5:05 UTC (permalink / raw)
  Cc: Drew Adams, emacs-devel

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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-05  5:05         ` display-buffer Nick Roberts
@ 2005-11-05  5:19           ` Luc Teirlinck
  2005-11-05  7:38             ` display-buffer Nick Roberts
  0 siblings, 1 reply; 16+ messages in thread
From: Luc Teirlinck @ 2005-11-05  5:19 UTC (permalink / raw)
  Cc: monnier, drew.adams, emacs-devel

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.

^ permalink raw reply	[flat|nested] 16+ messages in thread

* Re: display-buffer
  2005-11-05  5:19           ` display-buffer Luc Teirlinck
@ 2005-11-05  7:38             ` Nick Roberts
  0 siblings, 0 replies; 16+ messages in thread
From: Nick Roberts @ 2005-11-05  7:38 UTC (permalink / raw)
  Cc: monnier, drew.adams, emacs-devel

 >    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

^ permalink raw reply	[flat|nested] 16+ messages in thread

* display-buffer
@ 2014-01-13 19:36 Richard Stallman
  0 siblings, 0 replies; 16+ messages in thread
From: Richard Stallman @ 2014-01-13 19:36 UTC (permalink / raw)
  To: emacs-devel

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




^ permalink raw reply	[flat|nested] 16+ messages in thread

end of thread, other threads:[~2014-01-13 19:36 UTC | newest]

Thread overview: 16+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2005-11-03  0:25 display-buffer Nick Roberts
2005-11-03 16:09 ` display-buffer Drew Adams
2005-11-03 17:18   ` display-buffer Stefan Monnier
2005-11-03 19:32     ` display-buffer Drew Adams
2005-11-03 21:43     ` display-buffer Nick Roberts
2005-11-04  4:23       ` display-buffer Stefan Monnier
2005-11-05  5:05         ` display-buffer Nick Roberts
2005-11-05  5:19           ` display-buffer Luc Teirlinck
2005-11-05  7:38             ` display-buffer Nick Roberts
2005-11-03 21:40 ` display-buffer Richard M. Stallman
2005-11-03 21:49   ` display-buffer Drew Adams
2005-11-04  4:21     ` display-buffer Stefan Monnier
2005-11-04 10:45       ` display-buffer Eli Zaretskii
2005-11-05  1:36       ` display-buffer Richard M. Stallman
2005-11-05  1:37     ` display-buffer Richard M. Stallman
  -- strict thread matches above, loose matches on Subject: below --
2014-01-13 19:36 display-buffer Richard Stallman

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.