From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: select-frame-set-input-focus fails to raise the frame Date: Sat, 16 Dec 2017 16:39:13 +0200 Message-ID: <83d13espny.fsf@gnu.org> References: <20171213204737.GA1621@breton.holly.idiocy.org> <20171213222634.GA2144@breton.holly.idiocy.org> <831sjwt1jf.fsf@gnu.org> <83tvwrsouc.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Trace: blaine.gmane.org 1513435165 5670 195.159.176.226 (16 Dec 2017 14:39:25 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 16 Dec 2017 14:39:25 +0000 (UTC) Cc: alan@idiocy.org, emacs-devel@gnu.org To: rswgnu@gmail.com Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Dec 16 15:39:18 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 1eQDcT-0000te-Jp for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 15:39:17 +0100 Original-Received: from localhost ([::1]:50940 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQDca-0005tA-Ns for ged-emacs-devel@m.gmane.org; Sat, 16 Dec 2017 09:39:24 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33227) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQDcU-0005t3-LL for emacs-devel@gnu.org; Sat, 16 Dec 2017 09:39:19 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eQDcO-0001dM-3O for emacs-devel@gnu.org; Sat, 16 Dec 2017 09:39:16 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34181) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eQDcN-0001dF-Vc; Sat, 16 Dec 2017 09:39:12 -0500 Original-Received: from [176.228.60.248] (port=3486 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1eQDcN-0007uw-Ch; Sat, 16 Dec 2017 09:39:11 -0500 In-reply-to: (message from Robert Weiner on Sat, 16 Dec 2017 08:41:05 -0500) 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:221125 Archived-At: > 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 > ​​what you describe is Emacs working as designed. > > ​​​By 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.​ 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. On top of that, when and how a new frame appears on display is not only up to Emacs: the WM has a lot to do with that. > 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. The doc strings try very hard to tell the story completely and accurately, but it isn't easy, because the underlying behavior is extremely complex, and needs to cater to some very different use cases. Here's a rule of thumb I'd advise to anyone who tries to produce such "temporary" displays: it doesn't work with Emacs, at least not naively so, so my advice is to try finding other solutions. Using sit-for, especially in a multi-frame environment with mouse involved is extremely fragile for these purposes due to non-keyboard events involved that you cannot predict in advance. Calling 'redisplay' with last argument non-nil is the only way to actually ensure redisplay, so if you must, use only that. force-window-update is useless if redisplay doesn't happen, because it just sets an advisory flag for the display engine to consider. > If you look at the functions I have > enclosed, you will see the behavior I am trying to produce. I did, and still couldn't understand the intent. I still don't, FWIW.