GNU bug report logs - #745
pop-to-buffer, frames, and input focus

Previous Next

Full log

Message #105 received at 745 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: martin rudalics <rudalics <at> gmx.at>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 745 <at> debbugs.gnu.org, Chong Yidong <cyd <at> stupidchicken.com>,
        Stefan Monnier <monnier <at> IRO.UMontreal.CA>
Subject: Re: bug#745: pop-to-buffer, frames, and input focus
Date: Thu, 28 Aug 2008 23:26:51 +0200

> I know about the following problems:
>
>  1. pop-to-buffer doesn't switch input focus
>  2. select-window doesn't switch input focus
>  3. x-create-frame does switch input focus (with most WMs)
>
> Is there something else?

The XSetInputFocus vs x_ewmh_activate_frame dichotomy in
`x-focus-frame'.

> We agreed that we wont fix 3.

Yes.

> 1 would be fixed by calling select-frame-set-input-focus in
> pop-to-buffer (either customizable or not).  Do we need to test
> something?

Let's try without an option.  Stefan, Chong, any objections?

*** window.el.~1.146.~	2008-08-23 09:41:38.156250000 +0200
--- window.el	2008-08-28 19:32:50.765625000 +0200
***************
*** 1061,1066 ****
--- 1061,1067 ----
                   buf)))))
      (set-buffer buffer)
      (select-window (display-buffer buffer other-window) norecord)
+     (select-frame-set-input-focus (selected-frame))
      buffer))

  ;; I think this should be the default; I think people will prefer it--rms.

> Fixing 2 isn't so clear.  This was shortly discussed on the mailing list
> but RMS said, at that time, that more important things should be done.

You mean we could solve this with your update-focus-lazily approach?

martin

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.