From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Noam Postavsky 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: Wed, 27 Sep 2017 08:13:22 -0400 Message-ID: <87poacfifx.fsf@users.sourceforge.net> 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> <59A95A75.8040100@gmx.at> <87bmmu7czr.fsf@users.sourceforge.net> <59A980A5.9010705@gmx.at> <87zi9if9ux.fsf@users.sourceforge.net> <59CB5D18.2090806@gmx.at> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: blaine.gmane.org 1506514461 6474 195.159.176.226 (27 Sep 2017 12:14:21 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 27 Sep 2017 12:14:21 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.0.60 (gnu/linux) Cc: 25521@debbugs.gnu.org, qwxlea@gmail.com To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Sep 27 14:14:12 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 1dxBEA-00013P-LJ for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Sep 2017 14:14:10 +0200 Original-Received: from localhost ([::1]:54550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxBEH-0007a8-Tw for geb-bug-gnu-emacs@m.gmane.org; Wed, 27 Sep 2017 08:14:17 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38271) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dxBE8-0007a1-71 for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 08:14:13 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dxBE2-0008Eh-Ct for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 08:14:08 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:53854) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dxBE2-0008EY-7T for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 08:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dxBE2-0002bk-3G for bug-gnu-emacs@gnu.org; Wed, 27 Sep 2017 08:14:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Noam Postavsky Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 27 Sep 2017 12:14: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.15065144169986 (code B ref 25521); Wed, 27 Sep 2017 12:14:02 +0000 Original-Received: (at 25521) by debbugs.gnu.org; 27 Sep 2017 12:13:36 +0000 Original-Received: from localhost ([127.0.0.1]:34302 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxBDc-0002b0-6G for submit@debbugs.gnu.org; Wed, 27 Sep 2017 08:13:36 -0400 Original-Received: from mail-it0-f52.google.com ([209.85.214.52]:52508) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dxBDW-0002aj-SQ for 25521@debbugs.gnu.org; Wed, 27 Sep 2017 08:13:35 -0400 Original-Received: by mail-it0-f52.google.com with SMTP id c195so6270936itb.1 for <25521@debbugs.gnu.org>; Wed, 27 Sep 2017 05:13:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=uxjTMnpjX+pxQO26cYAn92bv+2ZJLxuJeviCQtNvUT0=; b=L4CKnoizQ88bqY5mERo0j7yBznO3fcNUIdJCO9sq9/P/7+u9h2hv2srJlbFvoNVvRv /YblwHz3pJWARKXCJ4x7XzsHLw2AZpc7kf3Z7rPnge3Y71FFjodr57ovn1uGM5GtRWSD 4M1WGPK06E1BeovtdkTN3l6dUOQZb/VionnAPcCTpcVqUMzBZZmlpmxb0B5GilUrnW7R 8mNBhGHInt71EshuMoLS5f1nnI+HPI63ytXaZ6mi4s/8aK2FfLFHwocePfDgLjHo0rSA Cni3dPEwaGonU0OCm0bTMaOahwAWqc5HwJF5XCOgKidjXZGkIrMxTg9AQH6sFBw9m2QO lWtA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:to:cc:subject:references:date :in-reply-to:message-id:user-agent:mime-version :content-transfer-encoding; bh=uxjTMnpjX+pxQO26cYAn92bv+2ZJLxuJeviCQtNvUT0=; b=a26Eig44ttu84PaMBQuY4p/clYBiK8CWoQSRYAHlNOvlvwNoNcrN7xo6AKy7rlY9Im +BfwwufcJZmozD4OM3TUu/aVrDZKTXZ5AauDOcVrlSi7YPV7Vr/+/bvqxiYR5CA6YBdB bxo5eu214EwND1dQ/LOoDkwBvQiFneo2VkxURFfDm9xZh7fm+539LVrRCfWy0jQxzDkz 1RI/LkO2Mv7Y4SyMe39/pg2AtrFDmwugydlYsqqklS037Dtqueng5qIsNMdcqPzNiKVl 4TDjY36r6/1ebI/AQAG2qMEYtus3vuwVk+wFK8sehuHtoSP0yHevgHBMsC0SvwwrK44d 4WIA== X-Gm-Message-State: AHPjjUgKe3Cph9mN81DIQ7YS0dc1//pJh67Fu438sRxwBeY7j55zk6fc zMiWMXvHyfblt/uK9DJ7iqc= X-Google-Smtp-Source: AOwi7QDZSCERKex8L4yiTxixVAkraJpg0mTQ9fELiAYtBOy7aUtGOdUb6X6zp5ZhWioto0qRRvwF4A== X-Received: by 10.36.105.142 with SMTP id e136mr151035itc.17.1506514404721; Wed, 27 Sep 2017 05:13:24 -0700 (PDT) Original-Received: from zebian ([45.2.119.34]) by smtp.googlemail.com with ESMTPSA id r139sm2312564itc.14.2017.09.27.05.13.23 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 27 Sep 2017 05:13:24 -0700 (PDT) In-Reply-To: <59CB5D18.2090806@gmx.at> (martin rudalics's message of "Wed, 27 Sep 2017 10:11:04 +0200") 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:137489 Archived-At: martin rudalics writes: > I would add to NEWS something like "'select-frame-by-name' now may > return a frame on another display if it does not find a suitable one on > the current display". Sure. > Is there anything I could tweak here to observe a visible impact? If I > set =E2=80=98x-wait-for-event-timeout=E2=80=99 to some large value nothin= g becomes > noticeable here, apparently because the frame is created fast enough. I think you might have to change window managers. For instance, when using i3, adding 'assign [class=3D"Emacs"] 9' to ~/.i3/config will make Emacs frames show up in workspace 9. When calling make-frame-command from a different workspace, Emacs will not get the message about frame visibility until you switch to workspace 9. (let ((x-wait-for-event-timeout nil)) (benchmark 1 '(make-frame-command)))"Elapsed time: 0.083540s" (let ((x-wait-for-event-timeout 0.1)) ; default (benchmark 1 '(make-frame-command)))"Elapsed time: 0.169369s" (let ((x-wait-for-event-timeout 100.0)) (benchmark 1 '(make-frame-command)))"Elapsed time: 1.338770s (0.05208= 3s in 1 GCs)" Hmm, that is actually less effect than I expected. I recall now that some non-relevant MapNotify events get sent in this case [1]. These make x_wait_for_event (f, MapNotify) return earlier than the previous busy wait. Should we wrap a timeout loop around the x_wait_for_event call? Or make the wait more selective (e.g., check that the given frame matches)? Seems a bit like overkill considering that a timeout of longer than 1 second is unlikely to be wanted, on the other hand, we're not really waiting for the right thing... [1]: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D24091#57 > (3) Install the =E2=80=98select-frame-by-name=E2=80=99 patch on the relea= se branch. > > The reason why I think that (3) is good to have despite of (1) is that > functions would behave reasonably well on systems where the user sets > the timeout to zero. Thus people who, for some reason, cannot or do not > want a larger timeout have a fallback. Differently put: A timeout of > zero should work well as default too. Yes, I agree with this.