From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics 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 09:23:47 +0200 Message-ID: <5AB9F183.3060306@gmx.at> 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> <83muyudyg1.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1522135330 29900 195.159.176.226 (27 Mar 2018 07:22:10 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Tue, 27 Mar 2018 07:22:10 +0000 (UTC) Cc: monnier@IRO.UMontreal.CA, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Tue Mar 27 09:22:06 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 1f0ivl-0007hk-Gs for ged-emacs-devel@m.gmane.org; Tue, 27 Mar 2018 09:22:05 +0200 Original-Received: from localhost ([::1]:60813 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0ixo-0003qZ-Pg for ged-emacs-devel@m.gmane.org; Tue, 27 Mar 2018 03:24:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55694) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1f0ixg-0003qH-UE for emacs-devel@gnu.org; Tue, 27 Mar 2018 03:24:05 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1f0ixd-0004we-QF for emacs-devel@gnu.org; Tue, 27 Mar 2018 03:24:04 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:56879) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1f0ixd-0004w9-FY; Tue, 27 Mar 2018 03:24:01 -0400 Original-Received: from [192.168.1.100] ([213.162.73.124]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0M2Glc-1ek1UG0cLM-00s7ot; Tue, 27 Mar 2018 09:23:56 +0200 In-Reply-To: <83muyudyg1.fsf@gnu.org> X-Provags-ID: V03:K0:teH92kLGI1YYfTFDEt9LPXNNCx4ymnpIKavos0SwBlkmwbIGPOt 6BWsLqNGx1dbFATBUZMIGtYoGjeYWdkLHPTUsNV0Sse/lWGtUWsTcBwrHd+HLOoWqxOsqiP 6s7XxSktQ0RBI/KxnXm9DfQHsE9kzf45LYfGIXQkstMjBMrPkJGVg00BUXpyqZ2XDHf3CZV iPfz0X3OQBfjxe4nZ8O8w== X-UI-Out-Filterresults: notjunk:1;V01:K0:KqpYEARrI7c=:ISgzaS6rzWxTsjgA6nVcwx N8mH7erxn8Q8jMMfnLZevFQUL6n8jgBN02XysEif5FWrXdzMrAJhqO6mqgbiZtr/x6KEwcvwf +CwDc6ivxooXGfkiBWM4ru/S8MdPS3j6PT6V1Q5Sn3Ew0NLeur619ZK902VyysSXYNrQq+S4d hNPkDVYQbDRCIGj6RIWxGeMurtvkyBg5xgiQcQD7vVR8yMN87QICwYJ9NnfIFkBH1y8MS75lv y+74rB+EGMbYfCQByQU/y07qnNE6Z9pJ6ZEJwEdqtQVV9jMC21qdTjwP4+PYVje1kvc6fT31z qwFQIhGBqlQzieGxMUIQWs+KHS0GpRcGdxtl+U+FbSMmsmwNCD5+f8kFpjL14SWv3GMNkSmgr T0sYvWlU21pyGKr3KJKLRJ7GLgW8LW1mO1JX72XT/MpatFQf0/9BNTCjvt4v63JJBetpPM3Px sb9PEZZwKVe5M9x+03SS6VfEIjiNT5fWlWEK4YGfEfMTKC3/2p25+NlVfAFNX4pCy9an//0Rp oggtRVdfHL5yWEuh/X3TRG48BjMG5dEic3xgFLf3M+eZKsPuATNX0e62uFZMKV1ZFSCe5/ser TAJQOpzhclWrK37dKEUOo1259VnuJXtGRqFl3okEc3mlHJ0IB7jFXLn1GSNgI0HCFGZuWxO/o bnXzE++SriUwX7Qr3MBZpz6vnrFdTOUerKV/kMaxoefkTcP14s6gxR9Ikj+4F+hMq5GQi9nEp eCYDOWccd8uHDtMszjqtYVC2UIyjjUo3s6HjGmTmlcE7d04cBMg+HKHUJEEuamWnczrwZMyX X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.17.21 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:224092 Archived-At: > 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. All I meant was that if FRAME_VISIBLE_P says that the frame is visible we should use that and we will find out soon enough if it doesn't tell us the truth. > 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. So x_make_frame_visible should not enter the loop when FRAME_VISIBLE_P returns non-zero but cannot rely on FRAME_VISIBLE_P to return non-zero in order to decide whether it's safe to leave the loop. martin