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 10:06:10 -0500 Message-ID: References: <20171213204737.GA1621@breton.holly.idiocy.org> <20171213222634.GA2144@breton.holly.idiocy.org> <831sjwt1jf.fsf@gnu.org> <83tvwrsouc.fsf@gnu.org> <83d13espny.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a113d7018eb562805607676c6" X-Trace: blaine.gmane.org 1513436825 25944 195.159.176.226 (16 Dec 2017 15:07:05 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 15:07:05 +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 16:07:00 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 1eQE3G-0005r2-4B for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 16:06:58 +0100 Original-Received: from localhost ([::1]:50991 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQE3I-0001Yy-AK for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 10:07:00 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:39970) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQE33-0001Ym-MN for emacs-devel@gnu.org; Sat, 16 Dec 2017 10:06:47 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQE30-0002Ox-E3 for emacs-devel@gnu.org; Sat, 16 Dec 2017 10:06:45 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34517) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQE30-0002Ot-AM for emacs-devel@gnu.org; Sat, 16 Dec 2017 10:06:42 -0500 Original-Received: from mail-qt0-f180.google.com ([209.85.216.180]:36184) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQE2z-0001NE-NW; Sat, 16 Dec 2017 10:06:41 -0500 Original-Received: by mail-qt0-f180.google.com with SMTP id a16so15460312qtj.3; Sat, 16 Dec 2017 07:06:41 -0800 (PST) X-Gm-Message-State: AKGB3mJOf3z36jzUmUDohD/9uSXMmkmW5AAThVcqtD0z7zfj7w2A/QXs BMWj2h6DzVK/yAo1hwlxbsBIErBDfhS7xFxuqn8= X-Google-Smtp-Source: ACJfBovVj69/NvNlQZmNgB9VByLZa1kYjDe6kazM72t3Q2dXPHjcfQpCqr0oibBbLMqiIJfvVnTHof0KEHmJBoS1yAo= X-Received: by 10.200.51.143 with SMTP id c15mr27921226qtb.46.1513436801093; Sat, 16 Dec 2017 07:06:41 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Sat, 16 Dec 2017 07:06:10 -0800 (PST) In-Reply-To: <83d13espny.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:221128 Archived-At: --001a113d7018eb562805607676c6 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sat, Dec 16, 2017 at 9:39 AM, Eli Zaretskii wrote: > > From: Robert Weiner > > Date: Sat, 16 Dec 2017 08:41:05 -0500 > > Cc: Alan Third , emacs-devel > > > > 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=8Bwhat you describe is Emacs working as designed. > > > > =E2=80=8B=E2=80=8B=E2=80=8BBy displayed temporarily, I mean that new fr= ame 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 > > Then IMO sit-for is not your friend: if input arrives soon enough, > redisplay will not be called. And if you happen to have > redisplay-dont-pause set to nil, even if redisplay _is_ called, it > might do nothing when sit-for calls it. > =E2=80=8BOk, that is an example of why I am advocating for a potentially new function that let's a programmer say "display the latest contents of this window with no other Emacs window or frame obscuring it". I don't think Elisp programmers should have to master the intricacies of windows, frames, the redisplay engine, and window managers to do that. Does anyone? =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > On top of that, when and how a new frame appears on display is not > =E2=80=8B=E2=80=8B > only up to Emacs: the WM has a lot to do with that. > =E2=80=8BYes, but Emacs sends commands to the WM. Now if the WM ignores those commands not much can be done but I think we are interested in the context where the WM responds as expected to the command and Emacs either gets a response or can poll to see if the WM state has changed. Take raise-frame for example. Should we not expect this to make the given frame the topmost? The doc string says we should. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > I should have noted that I first tried force-window-update (doc string > =E2=80=8B=E2=80=8B > > says it marks the given window to be redisplayed the next time redispla= y > =E2=80=8B=E2=80=8B > > runs) followed by a sit-for (doc string says it runs redisplay > unconditionally > =E2=80=8B=E2=80=8B > > until at least until any further input or timer expiration). That > combination > =E2=80=8B=E2=80=8B > > did not work either. Only the explicit call to redisplay worked. This > seems > =E2=80=8B=E2=80=8B > > to conflict with the doc strings to me. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > The doc strings try very hard to tell the story completely and > =E2=80=8B=E2=80=8B > accurately, but it isn't easy, because the underlying behavior is > =E2=80=8B=E2=80=8B > extremely complex, and needs to cater to some very different use > =E2=80=8B=E2=80=8B > cases. > =E2=80=8BI'm mainly asking that obvious gotchas like those demonstrated by my sample code be mentioned in doc strings, not a deep dive into all special case technicalities. =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Here's a rule of thumb I'd advise to anyone who tries to produce such > =E2=80=8B=E2=80=8B > "temporary" displays: it doesn't work with Emacs, at least not naively > =E2=80=8B=E2=80=8B > so, so my advice is to try finding other solutions. =E2=80=8BOk, I'm open and looking for input. Again, the use case is the idea of throwing a buffer to a new frame where you want the selected frame with input focus and its selected window PRIOR to the throw to be the same after the throw command but you need to show that the buffer has been thrown to the new frame and the new and the old frame largely overlap. After using the throw command, the user may soon choose to switch frames and work with the frame of the thrown buffer, so the frame must still exist after the throw command finishes. =E2=80=8B > Using sit-for, > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > especially in a multi-frame environment with mouse involved is > =E2=80=8B=E2=80=8B > extremely fragile for these purposes due to non-keyboard events > =E2=80=8B=E2=80=8B > involved that you cannot predict in advance. > =E2=80=8BOk. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Calling 'redisplay' with last argument non-nil is the only way to > =E2=80=8B=E2=80=8B > actually ensure redisplay, so if you must, use only that. > =E2=80=8BIt sounds like that is the only way since I need to see the curren= t contents of the new frame's only window. =E2=80=8B > =E2=80=8B=E2=80=8B > force-window-update > =E2=80=8B=E2=80=8B > is useless if redisplay doesn't happen, because it > =E2=80=8B=E2=80=8B > just sets an advisory > =E2=80=8B=E2=80=8B > flag for the display engine to consider. > =E2=80=8BI understand that. =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > > If you look at the fu > =E2=80=8B=E2=80=8B > nctions I have > =E2=80=8B=E2=80=8B > > enclosed, you will s > =E2=80=8B=E2=80=8B > ee the behavior I am trying to produce. > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > I did, and still couldn't understand the intent. I still don't, FWIW. > =E2=80=8BHave I explained it well enough to you now? Thanks, Bob =E2=80=8B=E2=80=8B --001a113d7018eb562805607676c6 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Dec 16, 2= 017 at 9:39 AM, Eli Zaretskii <el= iz@gnu.org> wrot= e:
> From: Robert Weiner <rsw@gnu.org>
> Date: Sat, 16 Dec 2017 08:41:05 -0500
> Cc: Alan Third <alan@idiocy.org>, emacs-devel <emacs-devel@gnu.org>
>
>=C2=A0 What do you mean by "displayed temp= orarily"?=C2=A0 As long as the current
>=C2=A0 command runs, Emacs will not enter redisplay; an explicit call t= o
>=C2=A0 'redisplay' is the only exception to that rule.=C2=A0 So= it sounds like
>=C2=A0 =E2=80=8B=E2=80=8Bwhat you describe is Emacs working as designed= .
>
> =E2=80=8B=E2=80=8B=E2=80=8BBy displayed temporarily, I mean that new f= rame 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

Then IMO sit-for is not your friend: if input arrives soon enough, redisplay will not be called.=C2=A0 And if you happen to have
redisplay-dont-pause set to nil, even if redisplay _is_ called, it
might do nothing when sit-for calls it.

=E2=80= =8BOk, that is an example of why I am advocating for a potentially
new fun= ction that let's a programmer say "display the latest
contents of= this window with no other Emacs window or frame
obscuring it".=C2=A0= I don't think Elisp programmers should have to
master the intricacies= of windows, frames, the redisplay engine,
and window managers to do that.= =C2=A0 Does anyone?

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

=E2=80=8B=E2=80=8B
On top of that, when and how a new frame= appears on display is not
=E2=80=8B=E2=80=8B
only up to Emacs: the WM has a lot to do= with that.

=E2=80=8BYes, but Emacs sends comman= ds to the WM.=C2=A0 Now if the WM ignores
those commands not much can be d= one but I think we are interested
in the context where the WM responds a= s expected to the command
and Emacs either gets a response or can poll to = see if the WM state
has changed.=C2=A0 Take raise-frame for example.=C2=A0= Should we not expect
this to make the given frame the topmost?=C2=A0 The = doc string says we
should.

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

=E2=80=8B=E2=80=8B
> I should have noted that I first tr= ied force-window-update (doc string
=E2=80=8B=E2=80=8B
> says it marks the given window to b= e redisplayed the next time redisplay
=E2=80=8B=E2=80=8B
> runs) followed by a sit-for (doc st= ring says it runs redisplay unconditionally
=E2=80=8B=E2=80=8B
> until at least until any further in= put or timer expiration).=C2=A0 That combination
=E2=80=8B=E2=80=8B
> did not work either.=C2=A0 Only the= explicit call to redisplay worked.=C2=A0 This seems
=E2=80=8B=E2=80=8B
> to conflict with the doc strings to= me.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
The doc strings try very hard to = tell the story completely and
=E2=80=8B=E2=80=8B
accurately, but it isn't easy, becau= se the underlying behavior is
=E2=80=8B=E2=80=8B
extremely complex, and needs to cater to= some very different use
=E2=80=8B=E2=80=8B
cases.

=E2=80= =8BI'm mainly asking that obvious gotchas like those demonstrated
=
by m= y sample code be mentioned in doc strings, not a deep dive
into all speci= al case technicalities.

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

=E2=80=8B=E2=80=8B
Here's a rule of thumb I'd advis= e to anyone who tries to produce such
=E2=80=8B=E2=80=8B
"temporary" displays: it doesn= 't work with Emacs, at least not naively
=E2=80=8B=E2=80=8B
so, so my advice is to try finding other= solutions.

=E2=80=8BOk, I'm open and looki= ng for input.=C2=A0 Again, the use case is the
idea of throwing a buffer t= o a new frame where you want the selected
frame with input focus and its s= elected window PRIOR to the throw to be
the same after the throw command b= ut you need to show that the buffer has
been thrown to the new frame and t= he new and the old frame largely overlap.

After using the throw comm= and, the user may soon choose to switch frames
and work with the frame of = the thrown buffer, so the frame must still exist
after the throw command f= inishes.

=E2=80= =8B
=C2=A0 Using sit-for,
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2= =80=8B=E2=80=8B
=E2=80=8B=E2=80=8B
=E2=80= =8B=E2=80=8B

=E2=80=8B=E2=80=8B
especially in a multi-frame environment = with mouse involved is
=E2=80=8B=E2=80=8B
extremely fragile for these purposes due= to non-keyboard events
=E2=80=8B=E2=80=8B
involved that you cannot predict in adva= nce.

=E2=80=8BOk.
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Calling 'redisplay' with last ar= gument non-nil is the only way to
=E2=80=8B=E2=80=8B
actually ensure redisplay, so if you mus= t, use only that.

=E2=80=8BIt sounds like that i= s the only way since I need to see the current contents
of the new frame&#= 39;s only window.
=E2=80=8B
=E2=80=8B=E2=80=8B
force-window-update
=E2=80=8B= =E2=80=8B
is useless if redisplay doesn't happen, because it
=E2=80=8B=E2=80=8B
just sets an advisory
=E2=80= =8B=E2=80=8B
flag for the display engine to consider.
=

=E2=80=8BI understand that.
=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
> If you look at the fu
=E2= =80=8B=E2=80=8B
nctions I have
=E2=80=8B=E2=80=8B
> enclosed, you will s
=E2= =80=8B=E2=80=8B
ee the behavior I am trying to produce.
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
I did, and still couldn't und= erstand the intent.=C2=A0 I still don't, FWIW.
=E2=80=8BHave I explained it well enough to you now?

Thanks,
Bob
=E2=80=8B=E2=80=8B

--001a113d7018eb562805607676c6--