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: display-until.el - Display a window or frame topmost in the frame stack until a condition or timeout occurs Date: Mon, 18 Dec 2017 13:17:04 -0500 Message-ID: References: <5A36B3B3.9040607@gmx.at> <5A376D9F.7000006@gmx.at> <83tvwoow4a.fsf@gnu.org> Reply-To: rswgnu@gmail.com NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a1148cce852c7de0560a15def" X-Trace: blaine.gmane.org 1513621843 21964 195.159.176.226 (18 Dec 2017 18:30:43 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 18 Dec 2017 18:30:43 +0000 (UTC) Cc: martin rudalics , emacs-devel To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Dec 18 19:30:39 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 1eR0BQ-0005K7-LH for ged-emacs-devel@m.gmane.org; Mon, 18 Dec 2017 19:30:36 +0100 Original-Received: from localhost ([::1]:51756 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eR0DO-0007mM-MF for ged-emacs-devel@m.gmane.org; Mon, 18 Dec 2017 13:32:38 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57362) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQzzn-0005sY-FB for emacs-devel@gnu.org; Mon, 18 Dec 2017 13:19:29 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQzyu-0006cf-JX for emacs-devel@gnu.org; Mon, 18 Dec 2017 13:18:28 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42306) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQzys-0006bK-Il for emacs-devel@gnu.org; Mon, 18 Dec 2017 13:17:38 -0500 Original-Received: from mail-qk0-f179.google.com ([209.85.220.179]:38881) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1eQzyp-0004kY-Jd; Mon, 18 Dec 2017 13:17:35 -0500 Original-Received: by mail-qk0-f179.google.com with SMTP id z203so19471914qkb.5; Mon, 18 Dec 2017 10:17:35 -0800 (PST) X-Gm-Message-State: AKGB3mKKLyBKTHOdWNyLoWGQW0nDhW6cUbSc5+hybfKUS34R6N+TbsmW asD82REG39J3GBs4GBeq+FvCwnUusJycrJAXGPQ= X-Google-Smtp-Source: ACJfBou3TpLSCy0GJhL/SOrgeIUVF04+xIXVaBPkf80sQf0cpgAB/64GAabjOLzoqh2Bta/Lk6nB9zMWkRO3OHnFEl4= X-Received: by 10.55.6.22 with SMTP id 22mr876088qkg.231.1513621055259; Mon, 18 Dec 2017 10:17:35 -0800 (PST) Original-Received: by 10.200.55.124 with HTTP; Mon, 18 Dec 2017 10:17:04 -0800 (PST) In-Reply-To: <83tvwoow4a.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:221220 Archived-At: --001a1148cce852c7de0560a15def Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Dec 18, 2017 at 11:10 AM, Eli Zaretskii wrote: > =E2=80=8B=E2=80=8B > > Date: Mon, 18 Dec 2017 08:26:23 +0100 > =E2=80=8B=E2=80=8B > > From: martin rudalics > =E2=80=8B=E2=80=8B > > Cc: emacs-devel > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > > =E2=80=8BPlease describe in detail what you see and what you think > =E2=80=8B=E2=80=8B > > > is wrong but update to 1.1 attached first.=E2=80=8B > =E2=80=8B=E2=80=8B > > > =E2=80=8B=E2=80=8B > > Here on Windows XP I mostly see an incompletely drawn frame with the > =E2=80=8B=E2=80=8B > > entire or parts of the toolbar missing, sometimes also a completely > =E2=80=8B=E2=80=8B > > blank frame. More or less what you described earlier in another thread= . > =E2=80=8B=E2=80=8B =E2=80=8B > =E2=80=8B=E2=80=8B > > =E2=80=8B=E2=80=8B > Which is quite expected, since the frame is created by a separate > =E2=80=8B=E2=80=8B > thread, and the display-until library doesn't give Emacs a chance to > =E2=80=8B=E2=80=8B > create it before it calls 'redisplay' (which has nothing to redisplay, > =E2=80=8B=E2=80=8B > as the frame is not official yet), and then immediately goes into the > =E2=80=8B=E2=80=8B > sleep-for loop (which doesn't redisplay). I think. > =E2=80=8BIf possible, shouldn't make-frame wait until the frame is created and mapped to the display if the creation command demands mapping? I guess you could start editing properties on =E2=80=8Ban as yet unmapped frame but in the general case, wouldn't a programmer want the frame and its constituent parts to exist prior to moving on? Since frame creation is done by a separate thread now, are all following operations on the frame queued until the whole frame is built or will they be lost if invoked during this interim creation period. For example, if I change an item on the toolbar prior to full toolbar creation, what happens? How can an Elisp programmer be sure the frame creation has finished without any reference to its creation thread? Bob =E2=80=8B=E2=80=8B --001a1148cce852c7de0560a15def Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Dec 18, 2= 017 at 11:10 AM, Eli Zaretskii <e= liz@gnu.org> wro= te:
<= blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px= #ccc solid;padding-left:1ex">
=E2=80=8B=E2=80=8B
> Date:= Mon, 18 Dec 2017 08:26:23 +0100
=E2=80=8B=E2=80=8B
> From: martin rudalics <rudalics@gmx.at>
=E2=80=8B=E2=80=8B
> Cc: emacs-devel <emacs-devel@gnu.org>
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
>=C2=A0 > =E2=80=8BPlease describe= in detail what you see and what you think
=E2=80=8B=E2=80=8B
>=C2=A0 > is wrong but update to 1= .1 attached first.=E2=80=8B
=E2=80=8B=E2=80=8B
>
=E2=80=8B=E2=80=8B
> Here on Windows XP I mostly see an = incompletely drawn frame with the
=E2=80=8B=E2=80=8B
> entire or parts of the toolbar miss= ing, sometimes also a completely
=E2=80=8B=E2=80=8B
> blank frame.=C2=A0 More or less wha= t you described earlier in another thread.
=E2=80=8B=E2=80=8B=E2=80=8B
=E2=80=8B=E2=80=8B

=E2=80=8B=E2=80=8B
Which is quite expected, since th= e frame is created by a separate
=E2=80=8B=E2=80=8B
thread, and the display-until library do= esn't give Emacs a chance to
=E2=80=8B=E2=80=8B
create it before it calls 'redisplay= ' (which has nothing to redisplay,
=E2=80=8B=E2=80=8B
as the frame is not official yet), and t= hen immediately goes into the
=E2=80=8B=E2=80=8B
sleep-for loop (which doesn't redisp= lay).=C2=A0 I think.

=E2=80=8BIf possible, shoul= dn't make-frame wait until the frame is
created and mapped to the disp= lay if the creation command
demands mapping?=C2=A0 I guess you could start= editing properties
on =E2=80=8Ban as yet unmapped frame but in the genera= l case, wouldn't
a programmer want the frame and its constituent parts= to
exist prior to moving on?

Since frame creation is done by a sep= arate thread now,
are all following operations on the frame queued until t= he
whole frame is built or will they be lost if invoked during
this inter= im creation period.=C2=A0 For example, if I change an
item on the toolbar = prior to full toolbar creation, what
happens?

How can an Elisp prog= rammer be sure the frame creation has
finished without any reference to it= s creation thread?

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

=
--001a1148cce852c7de0560a15def--