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 Mac port Date: Mon, 30 Oct 2017 09:25:46 +0100 Message-ID: <59F6E20A.4030806@gmx.at> References: <6EEBF320-A91F-4B19-B2E0-DED36B14E635@univie.ac.at> 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 1509351997 27084 195.159.176.226 (30 Oct 2017 08:26:37 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 30 Oct 2017 08:26:37 +0000 (UTC) Cc: emacs-devel@gnu.org To: YAMAMOTO Mitsuharu , Konrad Podczeck Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Oct 30 09:26:28 2017 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 1e95On-0005Yq-Mt for ged-emacs-devel@m.gmane.org; Mon, 30 Oct 2017 09:26:21 +0100 Original-Received: from localhost ([::1]:39153 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e95Ov-00045B-3u for ged-emacs-devel@m.gmane.org; Mon, 30 Oct 2017 04:26:29 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:44349) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1e95Og-000429-O7 for emacs-devel@gnu.org; Mon, 30 Oct 2017 04:26:18 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1e95Oc-0000Cy-PR for emacs-devel@gnu.org; Mon, 30 Oct 2017 04:26:14 -0400 Original-Received: from mout.gmx.net ([212.227.15.18]:53526) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1e95Oc-0000BM-G8 for emacs-devel@gnu.org; Mon, 30 Oct 2017 04:26:10 -0400 Original-Received: from [192.168.1.100] ([46.125.249.102]) by mail.gmx.com (mrgmx001 [212.227.17.190]) with ESMTPSA (Nemesis) id 0LwaQZ-1d5hjq3z0Z-018HXb; Mon, 30 Oct 2017 09:25:54 +0100 In-Reply-To: X-Provags-ID: V03:K0:rMo6MxOkcJEwti8+YMAJ3q39q0twLkDc4ANlcadiQICw6HKMKdk x37u5WpWTtdLrEpN4R5eIn77woAUaJjcLhqy0V1M/BI7JqRRH8YYyrSMLBi5BD5/B7s09Bv 4U7+pci1G6UHR6XtCaf2WQQGyDe59tsB11iTh0m8M0TbiWyEzbYI2AxXm/0irzkaKrQrFt/ atbdjUHkfG+PDz9d1yXPg== X-UI-Out-Filterresults: notjunk:1;V01:K0:5EAZtU3dusw=:7DEeqgViqrIRbGq1uTfCil qM9lORxmzfDC4mbh8NdyY3XvRjWeA7iDbFfA5HUv/7qtrCMR6gs5FCXsIkg7KZLqHdxuTvkFm j/PpmWA/TOEBT37FYRwWVar82BqafhD84Uq/GPC6lYft8F7+LV1G5HtDtKxg29AyYNWV9zz0/ EvlSeTFpinPt7RUflm+XL65NPtPp3Gxjqbxgzn6CM6vctQOxz3DLYZOxaPANg85BVvpY2Vofr CmoRepX9D0XnB76+8Chb1vbX0rNEVQvQmTL82uWASRLh8IMdGRk3e+ukwBk56TMKsdYds3f1V Aj+ZkaAiOebFIH0Npi4/DZKpac5nvaAr7KDUbD95ZME07Wnc6gyDxHblzDR7NwzPYtTFpgJm7 e+TuAf3o977FAuc4GxA5qzO05ClhDz6FSS9uWHhBB98i8s8HyC897qYX3pnVxspdgwZgyyRXL 0cVneCwMC/N84oTRhU+n4oUbSQo+EoJTBZArvapcsG8uKG/56/LbUT0qZpdl/CdB4vMAUMe1R leMiwfU/Rs62bajQ5jPofv5qsr14wLI2hHcEEkn2zKa3l8kBGU0Eq8k+JSal2r8IEIqpCpc22 CrOaWXm8OM2B0efYR0XE/TCE1pBYxFMdfkLaXHAgEBBvbiwSuLt+jtPon2100Au4z/7P4wOIf H0f7pQSuGFwTC6Hxh0z9i98yMZcgBFLix7ewv76h8/pI4qkJJ+huqqCMPxr8etJ5pPbhfT5mg FyY0YTYV1YQPY6Wu7xVtaTv/nzCX/CNc5DZ1pJ8tsaEqKnLejiOPS6j5db8ZcKZncZCjsTtj X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] [fuzzy] X-Received-From: 212.227.15.18 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:219825 Archived-At: >>> (2) Putting the mouse over a tool-bar button, so that the >>> corresponding tooltip appear, and then quickly dragging the frame >>> with the mouse to another place on the screen, the tooltip is still >>> shown for some time at the original screen position. How can you reproduce that? Here the tooltip disappears immediately when moving the mouse from the tool bar button to the frame border. > I think I could find the cause of this problem finally. It took a > long time because it was in the platform-independent part. I'm still > not sure if the patch below is the right way, but could you check if > this also works for your case? You mean that the help_echo_string built by if (cursor != FRAME_X_OUTPUT (f)->nontext_cursor) { /* Do we really want a help echo here? */ help_echo_string = build_string ("drag-mouse-1: resize frame"); goto set_cursor; should be immediately erased when we "have a window" and be left as is when we just "have a frame"? Or am I missing something else? martin