From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: martin rudalics Newsgroups: gmane.emacs.bugs Subject: bug#25521: 26.0.50; After (make-frame '((name . "foo"))) (select-frame-by-name "foo") doesn't see the frame Date: Fri, 01 Sep 2017 15:02:45 +0200 Message-ID: <59A95A75.8040100@gmx.at> References: <87a8agrwwx.fsf@gmail.com> <83lgtz3jdf.fsf@gnu.org> <87mvefk54q.fsf@gmail.com> <87inp2u2nn.fsf@users.sourceforge.net> <87r33qm4lh.fsf@gmail.com> <87a8adubtz.fsf@users.sourceforge.net> <877f5hq0tl.fsf@gmail.com> <87ziids1j2.fsf@users.sourceforge.net> <83vat10wdp.fsf@gnu.org> <87wp7ukw8x.fsf@users.sourceforge.net> <5955F510.5040101@gmx.at> <87efrr6rgx.fsf@users.sourceforge.net> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1504272428 3531 195.159.176.226 (1 Sep 2017 13:27:08 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 13:27:08 +0000 (UTC) Cc: 25521@debbugs.gnu.org, qwxlea@gmail.com To: npostavs@users.sourceforge.net Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Sep 01 15:26:54 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1dnlyA-0008Jn-EQ for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Sep 2017 15:26:46 +0200 Original-Received: from localhost ([::1]:40127 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnlyH-0003JJ-03 for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Sep 2017 09:26:53 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56799) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnlcK-0007YD-K7 for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 09:04:20 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dnlcA-00022H-Sk for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 09:04:12 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58962) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dnlcA-00022D-Q0 for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 09:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dnlcA-0003vA-FK for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 09:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 01 Sep 2017 13:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 25521 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 25521-submit@debbugs.gnu.org id=B25521.150427098815011 (code B ref 25521); Fri, 01 Sep 2017 13:04:02 +0000 Original-Received: (at 25521) by debbugs.gnu.org; 1 Sep 2017 13:03:08 +0000 Original-Received: from localhost ([127.0.0.1]:39410 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnlbH-0003u3-Ts for submit@debbugs.gnu.org; Fri, 01 Sep 2017 09:03:08 -0400 Original-Received: from mout.gmx.net ([212.227.17.21]:55652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dnlbF-0003tV-Ep for 25521@debbugs.gnu.org; Fri, 01 Sep 2017 09:03:05 -0400 Original-Received: from [192.168.1.100] ([46.125.250.108]) by mail.gmx.com (mrgmx103 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MXqV1-1e2IAA47Ut-00WjK1; Fri, 01 Sep 2017 15:02:50 +0200 In-Reply-To: <87efrr6rgx.fsf@users.sourceforge.net> X-Provags-ID: V03:K0:0iw7FdY58MT5A5BnLzhhZxbJRvMoNog6qnhhg6zP4/cXPM5BKgT jL+xug34E5s0KZyFVD/vYptSFVItowmGMtwEaVF5KBpajFSeCIx1zkfLv8J4s5OiiXcSSvl czXh0cWBc6FWtfc+n6AIe5/v0qEVF9J/FmiuK/UeSacJGMMDNsgcSqm2mNyx3BMlZ1RMgRk 5maJi3WIzXjrB/halwttQ== X-UI-Out-Filterresults: notjunk:1;V01:K0:rjQIEq2JbJY=:BsbePXK6zXmOb5zpffFvhU J7zrnJ3zELWhZMCG16c+H6GuWkJICJyOj0U3y9m7EYfH12oiXEsCL3HgBdAjlwQADxDaYbvwl 144tHSjSlRPKHyJE2rhUqxvRXkwD/weKeyImWpfmSfHqScikWqlo4WWP5YMujxZmwtdMiikEl 27qVJHq7PWQD4oYTd2Q37wXqIJWHz5mJnSy00F0TAm/erRbYFzcWB6deIxTZRaFHppsXT6MwC cYcAxe4mnsuPDXf2sv03/+EnkJD8NKZZUvAj5cj1WaW6Rl03qjFyLQ8CgIfn/v5KRvSC9yKcH 1uSGhS4qNaW2yk7s8md3rWd2SqzvkccZnL422g0KLFU1iAPLTTnuFiUWvPGtULsIMZqWMtj4d gYNVKMA+VDYwrrt/ctCUZ5rTBuKaZdVp6OqJ5d/WK41bdoP3bhPIpbcKxhGdWmA8klGq6AhkL Kqy5c/GxUsABqOtiw/1sMSijRuisQKIK/7+FSsb9fuAVSKt1ZTiQGw5BLO1bUtNx6AQSF0dnQ 5SCngrhstL9eZFyKQ1C9OSiuEB3mjBySPZR1R9nOQX6Iy5s/LqOV+GJ9o/9IkRuJ6ibOK7enR QvK67UYeob9XQ5m1/Bg+KWWef0uaJvaj4TwpDmEssml73MYOa+ycpObYsh1c/IjzMTazjfzSQ CSwNqDAuGBIwJT8VBOpnyRysmlFrpafI0zxMLfWHKkjvc9CJheMwDK/5KEnWt9s0xAAl7xVPj XgPFdZHttMuxq4gNxOiYuYJOuln0VqjD2aoWz2zIHLGkxbPIFuy5CjJbzD5Ms4nIirRe09HF X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:136441 Archived-At: > Hmm, I thought I could get away with using an existing hook. But > looking at all the places where x_make_frame_visible is called, I'm > feeling reluctant to introduce lisp evaluation into them. I think we > should go with Eli's idea, bring back the busy wait but add a timeout.= I'm not very convinced. First, the present bug should not motivate this change. =E2=80=98select-frame-by-name=E2=80=99 is a pretty obscure funct= ion. It fails in the OP's case because the display info for the new frame has not been yet set up. In the interactive call, suggesting a default frame on the current terminal makes sense; so consulting that info is useful. But the info is useless in a non-interactive call: Nothing should prevent that function from selecting a frame with a given name on any display. Second, we'll then have a third way how to wait on X for something to happen: We already have x_wait_for_event with a fixed 0.1 second timeout for frame resizing. And we have x_sync_with_move which counts till 50, may return early when the frame is within some fuzzy distance from the expected position and waits another 0.5 seconds if the frame hasn't made it there till then. martin