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#27647: 26.0.50; Line numbers implemented natively disappear momentarily when frame out of focus Date: Mon, 13 Nov 2017 19:45:40 +0100 Message-ID: <5A09E854.1000402@gmx.at> References: <83eftnitpj.fsf@gnu.org> <87inekjzy8.fsf@gmail.com> <87efp8jznq.fsf@gmail.com> <87shdo4150.fsf@users.sourceforge.net> <5A0403B7.3080309@gmx.at> <83shdnqwbw.fsf@gnu.org> <5A049A30.5000802@gmx.at> <83a7zvqilp.fsf@gnu.org> <5A081D9C.1000602@gmx.at> <83o9o7n2y8.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 1510598842 9230 195.159.176.226 (13 Nov 2017 18:47:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Mon, 13 Nov 2017 18:47:22 +0000 (UTC) Cc: 27647@debbugs.gnu.org, npostavs@users.sourceforge.net, agrambot@gmail.com, kaushal.modi@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Mon Nov 13 19:47:15 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 1eEJlK-0001v7-C0 for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 19:47:14 +0100 Original-Received: from localhost ([::1]:55895 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEJlP-0002Gu-RZ for geb-bug-gnu-emacs@m.gmane.org; Mon, 13 Nov 2017 13:47:19 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:56991) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1eEJlB-0002ER-ST for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:47:10 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1eEJl8-000885-KW for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:47:05 -0500 Original-Received: from debbugs.gnu.org ([208.118.235.43]:58387) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1eEJl8-00087h-GJ for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:47:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1eEJl8-0004hL-27 for bug-gnu-emacs@gnu.org; Mon, 13 Nov 2017 13:47:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: martin rudalics Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 13 Nov 2017 18:47:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 27647 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 27647-submit@debbugs.gnu.org id=B27647.151059876417989 (code B ref 27647); Mon, 13 Nov 2017 18:47:02 +0000 Original-Received: (at 27647) by debbugs.gnu.org; 13 Nov 2017 18:46:04 +0000 Original-Received: from localhost ([127.0.0.1]:38835 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEJkC-0004g4-7R for submit@debbugs.gnu.org; Mon, 13 Nov 2017 13:46:04 -0500 Original-Received: from mout.gmx.net ([212.227.17.22]:52080) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1eEJkA-0004fL-Co for 27647@debbugs.gnu.org; Mon, 13 Nov 2017 13:46:02 -0500 Original-Received: from [192.168.1.100] ([46.125.249.15]) by mail.gmx.com (mrgmx101 [212.227.17.168]) with ESMTPSA (Nemesis) id 0MGEv5-1eSsjk1bVf-00F9AH; Mon, 13 Nov 2017 19:45:47 +0100 In-Reply-To: <83o9o7n2y8.fsf@gnu.org> X-Provags-ID: V03:K0:9huDeZHnPhinrGh+RhrkXkJGS6+gGTxP9qx9baSV5pRcbkQg6Xm oNSObfrfJ0kXRHc6pmv9NCadmeyjLswjmyfwSKY7NGJdtLSfRo2zk8nBXXXBUC8zDqEiHuP CNRnUZSIsPl6yU4m47RbUrrEjR552WouW2IvsE6qTjsprJgeJdnZ+ehdeQGASNVYqg7YoXH 6QcojygVTzuJvxdYoj6sw== X-UI-Out-Filterresults: notjunk:1;V01:K0:8YoWGbtRTQk=:Kf2tdBXfHrSM6vN3dyQ9/E sLlCHcoWyhDSGot8DGx5Vfga5YnvbLiOgRINYri50OvbqAE71OLDl8BYrK68w2nJxI4BAn0bQ pOAr0YeAmkH4+bh8aJqG64yP/Fe9LE6hwoW5KGYfsfSLxicppZE/BDNaydLcmEj2zAXyenEyn G/28nvQ2qfzkd0xRQTACub0tXYw4WjJLOABzHIvyM9QZkXz8CaLEkwVbULndaeUbiC0HDLHBA PSXUVG9eRFHoYQ12gOyhVqKJWajH7Kx9d3m2Zf/S/5hCRgf0RpsMMb4J0fqq2l6bWXU9Jxr6w KR1xzxprzzJFBafXNxwijLTG06Y23Qvu3LYcLuIxQ3RAXk6PUTQmpQzwmqzI+BqTWJQ58cF9c cfJVUiABqawVgeSvMPKXoJ3EPb/DznHU397uSohwfR5OFoWThO7FZqarAUXrYzcHg2A6WxiK1 iALkkHYD+GLETSaFc9VLqSFFyxtf4x94iAtijpuidUy4i8VZ5cC9qg6gbsrHGH7SNhK70pr7b v7JzQgTz2WrwGb4ElkDLKbJX9dWlj3vyoKedYUHELq/Nxgh4Hrl6KUR2UvUl6kN9XJLdrPRcF XxK15TW1PMovbW+J+9L7cTawOoWoLsNl3IxU7GhdP6qAFipC+oJmMxpaJALyi2QJP2uTRTS8u JRGEEgSLMkceiVFsINilE09HmLmfTQyDNQDvNpai9CyuNsGey8siD9taeEM8pxk6cItPjjkiX ohrOV4cfZrqwP+X72obzeFcVPBhRyJcGyWNWki3Gyg6JXbBSaPuCkq3aN5FX1pp8BtwRzrv1 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:139840 Archived-At: > Not exactly. tip_frame should be nil when GTK pops a native tooltip, > then tip_frame will get its simple semantics back. x_hide_tip uses NILP (tip_frame) to decide whether to hide the tip. > If GTK needs to > stash the original frame, to be used to hide the tooltip, it should > use a separate variable (or a struct frame member), also with simple > semantics. Two variables with simple semantics are much better than > one with a subtly complex one. Don't you agree? IIUC GTK doesn't need the original frame. But it sets tooltip_frame to it so Fx_show_tip and friends can base their decisions on it. Look at occurrences of FRAMEP (tip_frame) and FRAME_LIVE_P (XFRAME (tip_frame)). They pass because for GTK tip_frame is a live frame associated with the tooltip. Jan tried hard to leave the native tooltip code untouched. > That timer was at the base of the proposed solution, AFAIU. So if you > dislike it, you dislike the idea itself. I don't dislike the timer. I dislike the idea to put it on a frame parameter. >> but maybe there really is no better solution. > > Sorry, I refuse to believe that. Where would you put it? >> Anyway, replacing the global variable and the frame parameter stuff >> by a one-bit per frame slot should be enough for fixing the mess at >> hand. > > Exactly. So why we need the rest of the complexity in that patch? Simply because I don't know whether the rest is more complex than what's needed to fix the mess. martin