From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Robert Weiner Newsgroups: gmane.emacs.devel Subject: Re: select-frame-set-input-focus fails to raise the frame Date: Sat, 16 Dec 2017 08:41:05 -0500 Message-ID: References: <20171213204737.GA1621@breton.holly.idiocy.org> <20171213222634.GA2144@breton.holly.idiocy.org> <831sjwt1jf.fsf@gnu.org> <83tvwrsouc.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114058a4a2c1bf056075463f" X-Trace: blaine.gmane.org 1513431760 11585 195.159.176.226 (16 Dec 2017 13:42:40 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 13:42:40 +0000 (UTC) Cc: Alan Third , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 14:42:36 2017 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eQCjc-0002iN-I5 for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 14:42:36 +0100 Original-Received: from localhost ([::1]:50741 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQCjj-0000ka-C7 for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 08:42:43 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48266) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQCij-0000kV-D7 for emacs-devel@gnu.org; Sat, 16 Dec 2017 08:41:42 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQCif-0007RB-EK for emacs-devel@gnu.org; Sat, 16 Dec 2017 08:41:41 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33535) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQCif-0007R0-Bm for emacs-devel@gnu.org; Sat, 16 Dec 2017 08:41:37 -0500 Original-Received: from mail-qt0-f175.google.com ([209.85.216.175]:43960) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQCie-0007BP-Oc; Sat, 16 Dec 2017 08:41:36 -0500 Original-Received: by mail-qt0-f175.google.com with SMTP id w10so15252887qtb.10; Sat, 16 Dec 2017 05:41:36 -0800 (PST) X-Gm-Message-State: AKGB3mLmAjCRtvfnYtGBx6Wv7hSfuGNbW0TBAfMP+JK+hHCKHYfgmoqh 4liSg1VJB+i0Q4+NP8T7JreUj9dImm8nDYcfAXE= X-Google-Smtp-Source: ACJfBovc2D5MuzTYXvStMhRFfZQR7EdQHooptPSM8IRiXzcLWMqEUO03lBaYvGboaMPockGGHJHQD9vLIC1cQrjrpmA= X-Received: by 10.200.38.33 with SMTP id u30mr28290075qtu.197.1513431696063; Sat, 16 Dec 2017 05:41:36 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 16 Dec 2017 05:41:05 -0800 (PST) In-Reply-To: <83tvwrsouc.fsf@gnu.org> X-Gmail-Original-Message-ID: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:221124 Archived-At: --001a114058a4a2c1bf056075463f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Dec 15, 2017 at 3:44 PM, Eli Zaretskii wrote: > > From: Robert Weiner > > Date: Fri, 15 Dec 2017 12:38:15 -0500 > > Cc: Alan Third , emacs-devel > > > > =E2=80=8BThe problem was that I would set-window-buffer in the new fram= e > > to a different buffer and that buffer would not display when > > the new frame was brought frontmost and displayed temporarily > > with a sleep-for delay. Calling force-window-update had no > > effect but calling (redisplay t) resolved it. > > What do you mean by "displayed temporarily"? As long as the current > command runs, Emacs will not enter redisplay; an explicit call to > 'redisplay' is the only exception to that rule. So it sounds like > =E2=80=8B=E2=80=8B > what you describe is Emacs working as designed. > =E2=80=8B=E2=80=8B =E2=80=8BBy displayed temporarily, I mean that new frame f2 and old frame f1 largely overlap one another and I want f2 to appear above f1 for a given delay, like half a second and then f1 to be raised atop it.=E2=80=8B I should have noted that I first tried force-window-update (doc string says it marks the given window to be redisplayed the next time redisplay runs) followed by a sit-for (doc string says it runs redisplay unconditionally until at least until any further input or timer expiration). That combination did not work either. Only the explicit call to redisplay worked. This seems to conflict with the doc strings to me. If you look at the functions I hav= e enclosed, you will see the behavior I am trying to produce. My broader argument is that one should be able to program utilizing window-based functions more simply when the windows involved exist in separate frames and an external window manager is involved. However, I see not everyone agrees with this, maybe because some of the behavior will always be asynchronous and possibly non-deterministic. Previously, I found Emacs handled mouse button drags between windows in different frames differently than drags between windows in a single frame. I was able to figure out a consistent model that now works well for me. I think this is similar, that with some work, managing windows across multiple frames can be made simpler and less-error prone than the way things are now. But if the major maintainers of Emacs are not very interested in this, then I don't expect anything to happen. Bob =E2=80=8B=E2=80=8B --001a114058a4a2c1bf056075463f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Dec 15, 2= 017 at 3:44 PM, Eli Zaretskii <el= iz@gnu.org> wrot= e:
> From: Robert Weiner <rsw@gnu.org>
> Date: Fri, 15 Dec 2017 12:38:15 -0500
> Cc: Alan Third <alan@idiocy.org<= /a>>, emacs-devel <emacs-devel= @gnu.org>
>
> =E2=80=8BThe problem was that I would set-window-buffer in the new fra= me
> to a different buffer and that buffer would not display when
> the new frame was brought frontmost and displayed temporarily
> with a sleep-for delay.=C2=A0 Calling force-window-update had no
> effect but calling (redisplay t) resolved it.

What do you mean by "displayed temporarily"?=C2=A0 As long= as the current
command runs, Emacs will not enter redisplay; an explicit call to
'redisplay' is the only exception to that rule.=C2=A0 So it sounds = like
=E2=80=8B=E2=80=8B
what you describe is Emacs working as de= signed.
=E2=80=8B=E2=80=8B
=E2=80=8BBy displayed temporar= ily, I mean that new frame f2 and old
frame f1 largely overlap one another= and I want f2 to appear
above f1 for a given delay, like half a second an= d then f1
to be raised atop it.=E2=80=8B

I should have noted th= at I first tried force-window-update (doc string
says it marks the given w= indow to be redisplayed the next time redisplay
runs) followed by a sit-fo= r (doc string says it runs redisplay unconditionally
until at least until = any further input or timer expiration).=C2=A0 That combination
did not wor= k either.=C2=A0 Only the explicit call to redisplay worked.=C2=A0 This seem= s
to conflict with the doc strings to me.=C2=A0 If you look at the functio= ns I have
enclosed, you will see the behavior I am trying to produce.
My broader argument is that one should be able to program utilizing wind= ow-based
functions more simply when the windows involved exist in separate= frames and an
external window manager is involved.=C2=A0 However, I see n= ot everyone agrees with this,
maybe because some of the behavior will alwa= ys be asynchronous and possibly
non-deterministic.

Previously, I = found Emacs handled mouse button drags between windows in different frames<= /div>
differently than drags between windows in a single frame.=C2=A0 I was able= to figure out a
consistent model that now works well for me.=C2=A0 I thin= k this is similar, that with some
work, managing windows across multiple= frames can be made simpler and less-error
prone than the way things are n= ow.=C2=A0 But if the major maintainers of Emacs are not very
interested in= this, then I don't expect anything to happen.

Bob

= =E2=80=8B=E2=80=8B

--001a114058a4a2c1bf056075463f--