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 17:45:41 +0200 Message-ID: <59A980A5.9010705@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> <59A95A75.8040100@gmx.at> <87bmmu7czr.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: 7bit X-Trace: blaine.gmane.org 1504282008 8764 195.159.176.226 (1 Sep 2017 16:06:48 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 1 Sep 2017 16:06:48 +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 18:06:39 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 1dnoSV-0000tt-VE for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Sep 2017 18:06:16 +0200 Original-Received: from localhost ([::1]:46717 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dnoSb-0001cm-BS for geb-bug-gnu-emacs@m.gmane.org; Fri, 01 Sep 2017 12:06:21 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:54692) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dno9z-0000WI-8F for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 11:47:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dno9u-0005TA-Bf for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 11:47:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:59948) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dno9u-0005T1-7z for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 11:47:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dno9t-0008GE-Ue for bug-gnu-emacs@gnu.org; Fri, 01 Sep 2017 11:47:01 -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 15:47:01 +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.150428076531690 (code B ref 25521); Fri, 01 Sep 2017 15:47:01 +0000 Original-Received: (at 25521) by debbugs.gnu.org; 1 Sep 2017 15:46:05 +0000 Original-Received: from localhost ([127.0.0.1]:40396 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dno8z-0008F3-AX for submit@debbugs.gnu.org; Fri, 01 Sep 2017 11:46:05 -0400 Original-Received: from mout.gmx.net ([212.227.17.22]:58363) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dno8x-0008EH-QM for 25521@debbugs.gnu.org; Fri, 01 Sep 2017 11:46:04 -0400 Original-Received: from [192.168.1.100] ([46.125.250.108]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0Lm7MT-1dECL30keP-00ZgOJ; Fri, 01 Sep 2017 17:45:44 +0200 In-Reply-To: <87bmmu7czr.fsf@users.sourceforge.net> X-Provags-ID: V03:K0:Vq+tHJZ6ZUYOfbbKF5hjDF+oOv9NcHCgdCPyOwxXCEMJqRviHZz nJgUJO6BO34IIj3itFljMgNTnbWPkynJsg9ctgCI1ryOV1xD7QyDUzhpEBjGPTW5o3MqmT4 2BW9PT0hpOFyMiUFEwwZs/CXr8QrViEuw0mCP6sl7k4kXSqWd2JIwBOn0XcLCJ1pzxiSfZS ZvOHt4UE5t1U495jiccrA== X-UI-Out-Filterresults: notjunk:1;V01:K0:23KuPahDWWg=:H4OihqW3LuL42PLX9hS6QH K8oIgf+2JR808IqT/XHjfsaobT7cdMMuWvUv7V/rIRZRj+wtxj8QUoWQSqPXoqTmD/dlBPzNa SK0t8l4aGpXc95JlFkP46CKCbrx6luQIOm++ghkXig4514yptD2CFz+BqOOHkJa4tVKR5ytYB J2j9b+H7ZVm8W7k9CIAzuoFToMxqezKWFUth2KCXNGV0tSzolCrRT08n7VJyLh32pdIi6csBp YaDf6itqNwGgcVnlJgvcRfMNchjSi9pGk5R/pPK4wtAmgeCFCbIxQ1vSmC0IYb0BdPlKasloI vWqOvbjZ5wmzXoNa2m6Sif/1HykiLAQLtfWl3M1v7/drPg/+BYZbngnA4ZOKpDhzeSra5JcOf jsAbVezu0SyLNzJiWEUK1PkVUMLxj+CEzoJzgFDlljA9Vp3RD6eEmjGJOqkoCkocY3asLy7wy LTzsi/YJux7d4VZbzQS5prAF+2MqBxmfuiPdh2uZJBPLOLzRp4mcHTYtccUizNOZG+RWcPuFI R4U7bNrSBeUdYUvEKV9OsysUlpCXGHjmkevLexXV1dNRS2Rn6lPZEtKYZWiTCy3X6u3gti/NS jjVAK6aeMDwP4lvBLm1HJ33xlo//WrTiaRpuqLrGMiMtDzsOSM3e4nBWDoMAbEAyr7JbYsDPK YTGCD+60+OvXFVekDJzLc6nS8VWqvmthJHRvRp4UBr6GzwCl/fiQ1DpCIa4uosDya0zxC4aba X70mFd2OXa27+aF3pDoCHeS0HV1FF+fUYFhTG50wqDPNsWSX0bY1b9sejoxCGagR4Cg+1xO4 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:136443 Archived-At: > Ah, so we could just do something like this? (untested) With a slightly amended doc-string, yes. If someone insists on having two frames with the same name on different displays and relying on the old behavior to choose the one on the same display, we could add such a check to give preference to a frame with the given name on the same display. I doubt that someone relies on this function to throw an error when a frame with the given name exists only on another display. Note that I'm not opposed to a timeout solution. As far as w32term.c is concerned, I think your solution is superior to the present one. But IMHO we should try to orchestrate all these efforts using a timer to synchronize Emacs with the window manager or window system in a uniform way so that the user knows where and how her time is spent. For example, if we decided that x_wait_for_event is a good idea, then we should implement it on Windows too and use it uniformly when waiting for a move frame event or the visibility confirmation. martin