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: Emacs-26.0.91: switch-to-buffer-other-window runs too slowly (about 0.1s) Date: Tue, 27 Mar 2018 05:50:06 +0300 Message-ID: <83muyudyg1.fsf@gnu.org> References: <83efk6g93z.fsf@gnu.org> <544b8346-bda9-45eb-9573-1d51d9f768b2@Spark> <83bmfag8gu.fsf@gnu.org> <87y3ie24z1.fsf@gmail.com> <87sh8m23tc.fsf@gmail.com> <87k1ty22p1.fsf@gmail.com> <837epyg30w.fsf@gnu.org> <83370mg0qj.fsf@gnu.org> <5AB94021.8080700@gmx.at> <83vadiek9y.fsf@gnu.org> <5AB94724.1020609@gmx.at> <83tvt2ej3g.fsf@gnu.org> <5AB96925.6080709@gmx.at> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1522118925 19852 195.159.176.226 (27 Mar 2018 02:48:45 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 02:48:45 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: martin rudalics Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 27 04:48:41 2018 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 1f0efA-000537-Oc for ged-emacs-devel@m.gmane.org; Tue, 27 Mar 2018 04:48:40 +0200 Original-Received: from localhost ([::1]:60061 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0ehD-0002Cw-Se for ged-emacs-devel@m.gmane.org; Mon, 26 Mar 2018 22:50:47 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57759) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0egP-0002Cd-Ne for emacs-devel@gnu.org; Mon, 26 Mar 2018 22:49:58 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0egN-0006Bk-5v for emacs-devel@gnu.org; Mon, 26 Mar 2018 22:49:57 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34322) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0egN-0006Be-2q; Mon, 26 Mar 2018 22:49:55 -0400 Original-Received: from [176.228.60.248] (port=4127 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1f0egM-0006Kq-ET; Mon, 26 Mar 2018 22:49:54 -0400 In-reply-to: <5AB96925.6080709@gmx.at> (message from martin rudalics on Mon, 26 Mar 2018 23:41:57 +0200) 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:224088 Archived-At: > Date: Mon, 26 Mar 2018 23:41:57 +0200 > From: martin rudalics > CC: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org > > > For the purposes of this discussion, I'll settle with a subset of my > > question, viz.: when FRAME_VISIBLE_P returns non-zero, is it possible > > that the frame is in fact not visible? > > > > If a non-zero value of FRAME_VISIBLE_P reliably tells us that the > > frame is visible, then we can avoid waiting for MapNotify when > > FRAME_VISIBLE_P returns non-zero at entry into x_make_frame_visible. > > (This is what the original code circa Emacs 21 did, AFAIR.) > > I mentioned my concerns because I obviously had the same idea. My > answer is simple: I think it's possible that FRAME_VISIBLE_P lies and > we should disregard that. If it lies, it's a good occasion to find > out and think of a fix for Emacs 27. > > And obviously I have no good ideas for Emacs 26. We are not talking about Emacs 26.1 in any case. It seems to me that if FRAME_VISIBLE_P can return non-zero when a frame is not visible, we are toast anyhow, because we have no reasonable way of telling whether a frame is or isn't visible. Waiting for 100 msec is not a guarantee for having the frame visible afterwards, certainly not if we don't make sure it is so at the end of the wait. So I'd like to see some evidence of such grave problems, before we go on with such a problematic assumption. FWIW, the original wait loop did use FRAME_VISIBLE_P as an indication of whether we need the wait at all: it would not enter the loop if FRAME_VISIBLE_P returned non-zero.